[PATCH] libinput device capability modification regarding combo input devices

[Derek Foreman]

On 24/09/15 07:38 PM, 박성진 wrote:
> Dear Bill Spitzak, thanks for your opinion. : )
> 
>  
> 
> As we know, there are a lot of keyboards or keyboard-like devices.
> 
> Some of them will be keypads or special keyboards for game or other
> purposes.
> 
> For those kinds of keyboards, we don’t need to care and we can deal with
> the events in the usual manner (e.g. send them to focus surface/window).
> 
>  
> 
> When it comes to mobile or TV, we can have another stories.
> 
> In mobile/TV, in some cases, we need to deal with a set of keys attached
> in the device in a special manner, therefore we need to distinguish the
> keys in the set from the normal keyboard keys.
> 
>  
> 
> For instance, in mobile, we can see some keys attached in our mobile
> devices.
> 
> Those kinds of keys are usually not for input texts but for triggering
> some actions.
> 
> In a usual application, volume up/down keys will be the keys for
> raising/lowering the volume.
> 
> By the way, in an application like a message application, volume up/down
> keys can be used to adjust the font size.

This sounds like it would make me very angry, especially if I wanted to
make the device quiet in a hurry. ;)

> Therefore each key attached in mobile device needs to be sent to each
> needed surface/window in a dynamically changeable delivery policy for
> each key because there are many applications which want to get a key
> even they don’t have the input focus.
> 
> Actually in many requirements in mobile devices, distinguishing between
> the normal(?) keyboards and the special set of key/buttons are needed
> and we need to have a key delivery manager which resides in a window
> manager for sending the special set of keys to the proper application(s).

Would it be possible to achieve this same effect by subdividing
keyboards virtually into multiple seats?  (multimedia keys into a
multimedia control seat, camera button to a seat named camera...)

The compositor or some manner of plug-in could handle this.  If an
application bound the seat containing the media keys they would be sent
to that app if it had keyboard focus... If no app bound that seat then
the compositor could use the keys internally to control volume levels,
launch camera app, etc...

I think perhaps the needed functionality is too high level for libinput...


(there's still a little more text below.)

> 
> Thanks and regards,
> 
> Sung-Jin Park
> 
>  
> 
> *From:*Bill Spitzak [mailto:spitzak at gmail.com]
> *Sent:* Friday, September 25, 2015 4:37 AM
> *To:* 박성진
> *Cc:* Andreas Pokorny; Peter Hutterer; wayland
> *Subject:* Re: [PATCH] libinput device capability modification regarding
> combo input devices
> 
>  
> 
>  
> 
>  
> 
> On Wed, Sep 23, 2015 at 6:52 PM, 박성진<sj76.park at samsung.com
> <mailto:sj76.park at samsung.com>> wrote:
> 
> Dear Andreas Pokorny, thanks for your reply. J
> 
>  
> 
> As you mentioned, we also need to distinguish between a full keyboard
> and a device which has a set of few keys.

I've written a patch to do just that:
http://patchwork.freedesktop.org/patch/48595

The intent being to add the ability to auto-hide a virtual keyboard if a
full keyboard is present...

I just need to get back to it and finish it up :)

Full keyboards can have multimedia keys as well though...

> Each key coming from the full keyboard will be sent to the focus
> surface(window).
> 
> However, a key coming from the device which has a few keys sometimes
> needs to be sent to the other surface(window) other than the focused
> surface(window).
> 
>  
> 
> Seems like the keyboard flag can just indicate a "full keyboard". It is
> hard to imagine an input device that does not have a few buttons so this
> can be assumed.