From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754470AbdA0I1g (ORCPT ); Fri, 27 Jan 2017 03:27:36 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:36744 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754248AbdA0I1H (ORCPT ); Fri, 27 Jan 2017 03:27:07 -0500 Subject: Re: [Xen-devel] [PATCH v2] xen, input: try to read screen resolution for xen-kbdfront To: Juergen Gross , linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, xen-devel@lists.xenproject.org References: <20170127071239.913-1-jgross@suse.com> <5cbb25fa-2dee-f82f-e656-bc733c67c398@gmail.com> <803639e7-e62e-cce1-6108-05a727612937@gmail.com> Cc: dmitry.torokhov@gmail.com From: Oleksandr Andrushchenko Message-ID: <3ec171a9-c38a-87e6-d1f6-5493211dc87e@gmail.com> Date: Fri, 27 Jan 2017 10:26:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >>>>> --- >>>>> 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 >>>>> #include >>>>> #include >>>>> +#include >>>>> #include >>>>> #include >>>>> @@ -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 > > Juergen