[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3] xen, input: add xen-kbdfront module parameter for setting resolution
On 12/04/17 20:26, Juergen Gross wrote: > On 12/04/17 18:24, Dmitry Torokhov wrote: >> On Wed, Apr 12, 2017 at 06:04:30PM +0200, Juergen Gross wrote: >>> On 12/04/17 17:16, Dmitry Torokhov wrote: >>>> Hi Juergen, >>>> >>>> On Tue, Apr 11, 2017 at 02:30:37PM +0200, Juergen Gross wrote: >>>>> Add a parameter for setting the resolution of xen-kbdfront in order to >>>>> be able to cope with a (virtual) frame buffer of arbitrary resolution. >>>>> >>>>> While at it remove the pointless second reading of parameters from >>>>> Xenstore in the device connection phase: all parameters are available >>>>> during device probing already and that is where they should be read. >>>>> >>>>> Signed-off-by: Juergen Gross <jgross@xxxxxxxx> >>>>> --- >>>>> V3: - merged the two patches >>>>> - read Xenstore parameters during probing of the device only >>>> >>>> I guess 2 module parameters are not big deal, but could you tell me why >>>> you can't always have them specified in Xenstore? >>> >>> This will depend on Xen version then. I'd prefer to have a way to >>> specify the resolution in case a new kernel is running as a guest >>> of an old Xen version. >> >> Who would be seeting up the kernel parameters in this case? User >> manually in guest bootloader config? > > Either the guest administrator through guest boot loader or the Xen > administrator in the guest config file. > > In the case where the problem has been reported (automatic tests of > graphical tools) this would be in the guest config file. > >>>> Also, I still think you are going in the wrong direction here. Can your >>>> framebuffer size change after booting the guest? If it can, you have to >>>> reconcile the new size and the coordinates reported by the pointing >>>> device, and I think guest should be doing it. If you look, for example, >>>> at vmmouse driver, they do not try to match coordinates it reports to >>>> the screen. >>> >>> I'm no expert in input driver interface. Can you tell me how the mouse >>> pointer is positioned in case of the vmmouse driver? Are the real limits >>> used just the minimum of pointing device and screen size limits? So >>> specifying a size of 0xffff * 0xffff like the vmmouse driver does will >>> work with any screen size being smaller than that? >> >> I think 0xffff is just the limits for coordinates reported through this >> interface; the expectation is that guest window size is not larger than >> that. I do not recall if the backend reports real screen pointer >> position, of offset from the (0,0) of guest's window, Thomas might tel >> you. IIRC code in vmware tools package (that runs in guest) gets >> notifications about screen changes and reacts accordingly. > > So a small test revealed that only with a resolution matching that of > the virtual console the virtual mouse pointer will be at the same > position as the real mouse pointer. Working with different resolutions > will require some sort of scaling available only if _both_ resolutions > are known. And as you don't like the input driver knowing about the > console I'm limited to fixed values via module parameters (taking into > account the embedded scenario without udev). Dmitry, are you okay with this now? I'd _really_ like to get this in - I'm trying for 3 months now. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |