lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 30 Jan 2017 13:27:29 +0200 From: Oleksandr Andrushchenko <andr2000@...il.com> To: Juergen Gross <jgross@...e.com>, Dmitry Torokhov <dmitry.torokhov@...il.com>, linux-kernel@...r.kernel.org, linux-input@...r.kernel.org, xen-devel@...ts.xenproject.org Subject: Re: [Xen-devel] [PATCH v2] xen, input: try to read screen resolution for xen-kbdfront On 01/30/2017 01:23 PM, Juergen Gross wrote: > On 27/01/17 17:10, Dmitry Torokhov wrote: >> On January 27, 2017 12:31:19 AM PST, Juergen Gross <jgross@...e.com> wrote: >>> On 27/01/17 09:26, Oleksandr Andrushchenko wrote: >>>> On 01/27/2017 10:14 AM, Juergen Gross wrote: >>>>> On 27/01/17 08:53, Oleksandr Andrushchenko wrote: >>>>>> On 01/27/2017 09:46 AM, Juergen Gross wrote: >>>>>>> On 27/01/17 08:21, Oleksandr Andrushchenko wrote: >>>>>>>> On 01/27/2017 09:12 AM, Juergen Gross wrote: >>>>>>>>> Instead of using the default resolution of 800*600 for the >>> pointing >>>>>>>>> device of xen-kbdfront try to read the resolution of the >>> (virtual) >>>>>>>>> framebuffer device. Use the default as fallback only. >>>>>>>>> >>>>>>>>> Signed-off-by: Juergen Gross <jgross@...e.com> >>>>>>>>> --- >>>>>>>>> V2: get framebuffer resolution only if CONFIG_FB (Dmitry >>> Torokhov) >>>>>>>>> --- >>>>>>>>> drivers/input/misc/xen-kbdfront.c | 15 ++++++++++++--- >>>>>>>>> 1 file changed, 12 insertions(+), 3 deletions(-) >>>>>>>>> >>>>>>>>> diff --git a/drivers/input/misc/xen-kbdfront.c >>>>>>>>> b/drivers/input/misc/xen-kbdfront.c >>>>>>>>> index 3900875..3aae9b4 100644 >>>>>>>>> --- a/drivers/input/misc/xen-kbdfront.c >>>>>>>>> +++ b/drivers/input/misc/xen-kbdfront.c >>>>>>>>> @@ -16,6 +16,7 @@ >>>>>>>>> #include <linux/kernel.h> >>>>>>>>> #include <linux/errno.h> >>>>>>>>> #include <linux/module.h> >>>>>>>>> +#include <linux/fb.h> >>>>>>>>> #include <linux/input.h> >>>>>>>>> #include <linux/slab.h> >>>>>>>>> @@ -108,7 +109,7 @@ static irqreturn_t input_handler(int rq, >>> void >>>>>>>>> *dev_id) >>>>>>>>> static int xenkbd_probe(struct xenbus_device *dev, >>>>>>>>> const struct xenbus_device_id *id) >>>>>>>>> { >>>>>>>>> - int ret, i; >>>>>>>>> + int ret, i, width, height; >>>>>>>>> unsigned int abs; >>>>>>>>> struct xenkbd_info *info; >>>>>>>>> struct input_dev *kbd, *ptr; >>>>>>>>> @@ -173,9 +174,17 @@ static int xenkbd_probe(struct >>> xenbus_device >>>>>>>>> *dev, >>>>>>>>> ptr->id.product = 0xfffe; >>>>>>>>> if (abs) { >>>>>>>>> + width = XENFB_WIDTH; >>>>>>>>> + height = XENFB_HEIGHT; >>>>>>>>> +#ifdef CONFIG_FB >>>>>>>>> + if (registered_fb[0]) { >>>>>>>> This still will not help if FB gets registered after kbd+ptr >>>>>>> Hmm, so you think I should add a call to fb_register_client() to >>> get >>>>>>> events for new registered framebuffer devices? >>>>>> yes, but also pay attention to CONFIG_FB_NOTIFY: you may still >>>>>> end up w/o notification. >>>>> Okay, that's not worse than today. >>>> agree >>>>>>> This would probably work. I'll have a try. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Juergen >>>>>> My bigger concern here is that we try to tie keyboard and pointer >>> device >>>>>> to the framebuffer. IMO, these are independent parts of the system >>> and >>>>>> the relation >>>>>> depends on the use-case. One can have graphics enabled w/o >>> framebuffer >>>>>> at all, e.g. >>>>>> DRM/KMS + OpenGLES + Weston + kbd + ptr... >>>>> Again: that's a use case which will work as today. The current >>> defaults >>>>> are being used. >>>>> >>>>> The question is whether we should add a module parameter switching >>> off >>>>> the automatic adaption of the resolution as there might be use cases >>>>> where we don't want this feature. >>>> I think for those who doesn't want this resolution there is >>>> still a possibility to change it on backend's XenbusStateConnected >>>> So, no need for module parameter, IMO >>> Fine. >>> >>> I'll send V3 soon. >> How about you do the axis adjustment from userspace (udev rule), and leave kernel as is? > Hmm, is this a good idea? > > I'd need a udev rule to trigger when either the pointing device or a > new frame buffer is showing up. In both cases I need to read the > geometry of the frame buffer (in case it exists) and set the geometry > of the pointing device (in case it exists) to the same values. This > seems to be much more complicated than the required changes in the > driver. > > I could be wrong, of course, especially as I'm no expert in writing > udev rules. :-) And you may also end up with thin Dom0 w/o udev at all... > > Juergen
Powered by blists - more mailing lists