Using Soft Keys with Weston & Libinput

[Peter Hutterer]

On Fri, Feb 05, 2016 at 10:19:55AM +0000, Ucan, Emre (ADITG/SW1) wrote:
> Hello Peter,
> 
> Thank you for your answer. My comments are below.
> 
> > -----Original Message-----
> > From: Peter Hutterer [mailto:peter.hutterer at who-t.net]
> > Sent: Freitag, 5. Februar 2016 07:16
> > To: Ucan, Emre (ADITG/SW1)
> > Cc: wayland-devel at lists.freedesktop.org; Friedrich, Eugen (ADITG/SW1)
> > Subject: Re: Using Soft Keys with Weston & Libinput
> > 
> > On Thu, Feb 04, 2016 at 10:38:18AM +0000, Ucan, Emre (ADITG/SW1) wrote:
> > > Hi,
> > >
> > > We want to use soft keys with weston.
> > >
> > > The use-case is very similar to android that the touch panel is bigger than
> > the display.
> > > The out of display touch events should be routed to the clients as key
> > events.
> > >
> > > As far as I understood, It is not possible to realize this use-case in
> > > current weston implementation, because the coordinates of touch events
> > are scaled to width and height of the display with
> > libinput_event_touch_get_x(y)_transformed API.
> > >
> > > For example, when I touch a soft key (outside of display), the grab
> > > interface will still get a touch event in the range of display width and height,
> > and It will wrongly route this event to a wl_surface which is on the edge of
> > the display. Weston cannot recognize that the event happened outside of
> > the display.
> > >
> > > Is there a way to realize this use-case that I do not know ?
> > 
> > short answer: you'll need code in weston to handle this.
> > 
> > libinput doesn't care about the display, it merely takes the touch coordinates,
> > the API then tells libinput to scale the range into that coordinate set. If you
> > screen has an offset, you need to detect that and handle it separately but
> > that is not something weston currently does.
> > 
> > with the current APIs what you'll need to do is check the mm value for the
> > display, calculate if it is outside the boundary you want and handle it
> > accordingly. if it is within the display boundary, then you can pass it on
> > normally.
> 
> I think it is not correct to solve this problem in weston. How will I get mm value for the display in input.c ?
> I am not sure but we can get DPI information maybe from DRM. This would not work in current architecture of weston, because only drm backend plugin has access to drm device.
> 
> I am sending a picture of a head-unit for visualization of the use-case:
> 	- On the left upper corner there is the shutdown soft key
> 	- On the left side of display there is the volume slider which should send axis events.
> 	- On the right side there are other soft keys.
> 
> A similar problem is solved in libinput for touchpads:
> 
> 	- If specific parts of touchpad is pressed, a button event is sent via evdev-mt-touchpad-buttons.c
> 	- If specific parts of touchpad is pressed, an axis event is sent via evdev-mt-touchpad-edge-scroll.c
> 
> My idea is to extend this implementation to support key events (i.e evdev-mt-touchpad-keys.c) and configure location of soft keys via udev-rules.
> 
> The soft-keys is a very important use-case for embedded devices, and I know that libinput is a DE oriented project.
> But  I want to share this implementation (when it is finished), if it is interesting for the community.

ok, looking at this picture it shows that this is a bit different than what
I originally expected. I thought you were talking about displayed softkeys
like the music/phone/??? buttons in the top right corners of your photo.

The ones you're talking about are quite separate, so yes, there is room for
this in libinput and it should be solved there.  Mainly because this
effectively a hardware feature.

Addressing this in libinput brings up a few questions. The first would be:
how are the softbuttons to be handled - as a separate interface or as simple
key presses? second, how to integrate them in the back-end. udev rules will
be the core of the solution, but it also comes down to deciding on a format
to describe these buttons correctly. Then obviously we need a mechanism to
reduce the active area of this touchscreen to the actual display parts.

one concern I have with all this is testing. most of the devices won't be
desktop devices and likely be once-off devices that we cannot ever test.
So we need to make sure we specify the behaviour in a lot of detail and have
test-cases for all of these behaviours to avoid regressions.

Aside from all this, yeah, this can be in libinput.

Cheers,
   Peter