touch screen API resources?
#1
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?
#2
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/Softwa...board.html
#3
(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:
https://developer.puri.sm/Librem5/Softwa...board.html
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.
#4
(08-05-2020, 12:04 PM)Rich_Morin Wrote:
(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:
https://developer.puri.sm/Librem5/Softwa...board.html
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.
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.
#5
(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?
#6
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.
#7
(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?
#8
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.


Possibly Related Threads…
Thread Author Replies Views Last Post
  sms app is outside of screen cant send sms right now.. quick fix? temp0rary 2 198 06-02-2021, 02:12 PM
Last Post: temp0rary
  vivaldi only uses half the screen for website display motox6 0 205 05-22-2021, 03:49 PM
Last Post: motox6
  Default SMS app send button off screen in vertical orientation motox6 0 171 05-22-2021, 02:55 PM
Last Post: motox6
  Mobian screen won't wake reliably. StridAst 5 686 05-05-2021, 12:07 PM
Last Post: motox6
  Anbox apps listed in the launch screen mark1250 1 490 03-17-2021, 02:23 PM
Last Post: tvall
  OpenTTD game - Error: no usable screen resolutions found. eugenr 2 499 03-15-2021, 11:16 AM
Last Post: eugenr
  Mobiian Community edition issue after spalsh screen ashley123 14 1,792 03-08-2021, 05:34 AM
Last Post: wibble
Question Mobian screen dims JustineSmithies 12 5,588 01-18-2021, 08:54 AM
Last Post: fheuxjxhd
  screen goes blank when I insert pinephone dock, or usb-a to usb-c adaptor rp3 3 706 01-12-2021, 05:06 AM
Last Post: rp3
  Make 'terminal' on-screen keyboard the default 3x5co 0 492 12-27-2020, 05:11 PM
Last Post: 3x5co

Forum Jump:


Users browsing this thread: 1 Guest(s)