[Development] Multiseat capability to Qt

[Girish Ramakrishnan]

On Fri, Apr 13, 2012 at 3:20 AM, Samuel Rødal <samuel.rodal at nokia.com> wrote:
> On 04/13/2012 11:37 AM, ext Hannu Lyytinen wrote:
>> Hello all,
>>
>> after doing some small fixes to KMS QPA plugin, I proceeded with
>> implementing the input device support via evdev. It was soon pointed out
>> that perhaps using the generic evdev plugins would be better idea. I
>> experimented with them a bit and seems they need some work.
>> Specifically, all these plugins generate the events via
>> QWindowSystemInterface::handle{Key,Mouse}Event, with the first parameter
>> being set to null. Same applies to handleTouchEvent, but touch handling
>> is a bit more hairy so let's skip it for the sake of clarity.
>>
>> Looking at QGuiApplicationPrivate::processKeyEvent reveals that for KMS
>> the key event is always discarded and in processMouseEvent the event
>> gets delivered to first available screen in practice.
>>
>> Currently the KMS QPA plugin works with multiple screens and I would
>> like to assign the input devices to these screens via the ID_SEAT
>> attribute in the udev database. In other words, a screen and a number of
>> input devices like keyboards and mouses would be bound into a single
>> seat. This would also solve my problem; the evdev plugins could be
>> modified to send the events to the toplevel window associated with the
>> given screen (which in turn is associated to the given input device).
>>
>> I'm inclined towards adding a new interface to QPA API, namely
>> QPlatformSeat. The platform plugins could implement their own grouping
>> for the screen and the input devices.
>>
>> Any comments?
>
> Isn't this just a question of the platform plugin delivering a given
> input event to the correct window? What API did you have in mind for
> QPlatformSeat in relation to QPlatformScreen and input handling?
>
> Speaking about the generic evdev plugins, maybe we should enable them to
> both be stand-alone as they currently are, or to be compiled into the
> platform plugin itself for greater control. That way most of the code
> could be shared, and the evdev plugins could act either as helper
> libraries or as generic plugins.
>

Agree with Samuel here. The input plugins can be made smart enough to
iterate through the screen list and locate the correct target window.
Currently, the generic plugins are used only by eglfs which only has
one window and as a result passing 0 as window argument worked fine.

Girish