+- PINE64 (https://forum.pine64.org)
+-- Forum: PinePhone (https://forum.pine64.org/forumdisplay.php?fid=120)
+--- Forum: PinePhone Software (https://forum.pine64.org/forumdisplay.php?fid=121)
+---- Forum: Mobian on PinePhone (https://forum.pine64.org/forumdisplay.php?fid=139)
+---- Thread: touch screen API resources? (/showthread.php?tid=10961)
touch screen API resources? - Rich_Morin - 08-05-2020
The PinePhone touch screen controller GT917S datasheet contains a lot of useful-looking information, but (of course) it says nothing about the API(s) that can be used to access the controller. I'm interested in supporting braille input on a PinePhone, probably on Mobian and/or pmOS. Can anyone point me to some relevant resources?
RE: touch screen API resources? - wibble - 08-05-2020
I guess you're looking to provide an alternative to the usual on-screen keyboard, in which case the squeekboard docs are probably a good place to start:
https://developer.puri.sm/Librem5/Software_Reference/Environments/Phosh/Squeekboard.html
RE: touch screen API resources? - Rich_Morin - 08-05-2020
(08-05-2020, 10:57 AM)wibble Wrote: I guess you're looking to provide an alternative to the usual on-screen keyboard, in which case the squeekboard docs are probably a good place to start:I'll take a look, but by way of context, this would normally be used by blind folks, so the screen image aspects aren't all that critical.
https://developer.puri.sm/Librem5/Software_Reference/Environments/Phosh/Squeekboard.html
RE: touch screen API resources? - wibble - 08-10-2020
(08-05-2020, 12:04 PM)Rich_Morin Wrote:I was thinking more in terms of how it maps touch inputs to keyboard input for weyland. Without knowing more about what you're aiming to do it's hard to know whether you'd be looking at accessing the kernel driver interface directly (under /dev/input/ I expect) or providing an alternate input method at the X or wayland level to use existing desktops with their respective accessibility features. Each has a different way of doing things.(08-05-2020, 10:57 AM)wibble Wrote: I guess you're looking to provide an alternative to the usual on-screen keyboard, in which case the squeekboard docs are probably a good place to start:I'll take a look, but by way of context, this would normally be used by blind folks, so the screen image aspects aren't all that critical.
https://developer.puri.sm/Librem5/Software_Reference/Environments/Phosh/Squeekboard.html
RE: touch screen API resources? - Rich_Morin - 08-10-2020
(08-05-2020, 10:57 AM)wibble Wrote: I was thinking more in terms of how it maps touch inputs to keyboard input for Wayland. Without knowing more about what you're aiming to do, it's hard to know whether you'd be looking at accessing the kernel driver interface directly (under /dev/input/ I expect) or providing an alternate input method at the X or Wayland level to use existing desktops with their respective accessibility features. Each has a different way of doing things.
Actually, I'm not really sure how my code should link in to the rest of the system and the other apps. The other BSI implementations I know about run on Android, Fire OS, and iOS. None of these are going to be the same as a "normal" Linux system, so I can't just copy their approaches.
It appears that Squeekboard uses D-Bus, which seems like a promising approach. Also, it might be possible to leverage Squeekboard in some manner (e.g., pretending to be an add-on hardware keyboard). Does D-Bus seem like a reasonable starting point?
RE: touch screen API resources? - wibble - 08-10-2020
About the closest I've come is seeing that there are accessibility options in the settings panel of most of the significant desktop environments. I'm not familiar with how they're used, or how standard they may be.
Unless I'm missing something the dbus interface is only for showing/hiding the virtual keyboard, unless squeekboard is using the feedbackd dbus interface for haptic feedback. Touch events for the 'keys' are collected via gtk3 which should work with either X or wayland. I think they're sent out using the wayland virtual keyboard protocol, so you'd have to do it differently if you were using X rather than wayland.
RE: touch screen API resources? - Rich_Morin - 08-11-2020
(08-10-2020, 06:58 PM)wibble Wrote: ... Touch events for the 'keys' are collected via gtk3 which should work with either X or wayland. I think they're sent out using the wayland virtual keyboard protocol, so you'd have to do it differently if you were using X rather than wayland.Thanks, I'll look into gtk3. I'd like this code to run under both postmarketOS and Mobian; can you tell me anything about how this might affect things?
RE: touch screen API resources? - wibble - 08-11-2020
I think the main difference you'll see is that the packaging process is slightly different - debian for mobian vs. alpine linux for PostmarketOS. Both are capable of running other desktops (Plasma Mobile etc.) but most of the effort seems to be concentrated around Phosh which has its roots in Gnome, hence the gtk3 use. If you went the Plasma Mobile route then Qt would probably be the better option. I _think_ both Mobian and PmOS are concentrating on wayland over X with most desktops, but I may be wrong.