Skip to content
Snippets Groups Projects
New look: Off

medion-kai: responsive area shifted left from where keyboard is displayed on screen

    • Closed Imported Issue created by Administrator @root

    Trying to follow the porting guide for new devices on medion kai, running osk-sdl from within pmos with

    export DFBARGS="system=fbdev,no-cursor,disable-module=linux_input"
export TSLIB_TSDEVICE=/dev/input/event1
osk-sdl -d a -n a -c /etc/osk.conf -v

    Contens of /etc/fb.modes

    mode "1280x800-0"
    # D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz
    geometry 1280 800 1280 800 16
    timings 0 0 0 0 0 0 0
    accel false
    rgba 8/0,8/8,8/16,8/24
endmode

    The issue is that the screen area that will generate keystrokes is shifted to the left from the area where the keyboard is displayed. For example, tapping the ↑ key will trigger the ← event.osk_sdl_shiftedosk_out.log

    Edited
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • Administrator changed the description · Imported

      changed the description

      By red-black-bonsai on 2020-01-25T19:39:40

    • Administrator
      Administrator @root · Imported
      Author Owner

      Maybe this is a kernel driver issue? Does it work in any UI after postmarketOS booted?

      By Oliver Smith on 2020-01-26T22:09:52

    • Administrator
      Administrator @root · Imported
      Author Owner

      What do you mean by "it"? The touchscreen is working fine with the weston demo, with no calibration file required. And I'm testing osk-sdl from pmos after boot (logging in via ssh and starting as described above). I guess I may be misunderstanding your question.

      By red-black-bonsai on 2020-01-27T21:44:11

    • Administrator
      Administrator @root · Imported
      Author Owner

      This is probably a bug in osk-sdl, but this package looks abandoned, so I doubt it will be fixed. But you can try your self of course :)

      By Alexey Min on 2020-01-27T23:50:48

    • Administrator
      Administrator @root · Imported
      Author Owner

      Yeah - I thought I'd leave a description of the issue here in case the package was revived. I might try my hand at it but tbh I first have to get a better understanding of the pmOS ecosystem.

      By red-black-bonsai on 2020-01-28T09:08:37

    • Administrator
      Administrator @root · Imported
      Author Owner

      What do you mean by "it"? The touchscreen is working fine with the weston demo, with no calibration file required

      Yes, with "it" I meant the touchscreen. Okay, with that information, it seems like a osk-sdl bug indeed.

      I might try my hand at it but tbh I first have to get a better understanding of the pmOS ecosystem.

      Here's the workflow for modifying the code and building it as postmarketOS package:

      $ cd ~/code
$ git clone https://gitlab.postmarketos.org/postmarketos/osk-sdl/
$ cd osk-sdl
$ nvim src/main.cpp # make changes somewhere
$ pmbootstrap build osk-sdl --arch=armhf --src=~/code/osk-sdl

      Then you can copy the new package to the device, either with scp or with this guide:

      https://wiki.postmarketos.org/wiki/Installing_packages_on_a_running_phone

      (I'm not sure if we should call osk-sdl abandoned - it's true that there is no development going on... but it's still working and supported; and once postmarketOS comes closer to daily driver level, having a working UI for full disk encryption will be pretty important.)

      By Oliver Smith on 2020-01-31T01:11:33

    • Administrator
      Administrator @root · Imported
      Author Owner

      Damn, if you're so nice and encouraging about it, I have to actually try! And it's been ages since I've worked with C++ :D

      First thoughts: It looks to me like the code was developed with the assumption that height would mostly be greater than the width of the device; there's a lot of scaling/changing of y/height values but not of x/width values. Main usecase is phone, not tablet? This doesn't hold in my case -> untested edge case?

      From looking at the code and debug output, it's interesting that I'm getting a lot of

      xMouse: 416	yMouse: 583

      and not

      xTouch: 416	yTouch: 583

      So... I end up in the mouse branch of the code rather than the touchscreen branch. Don't know yet if that's significant.

      I'm too tired to make useful progress now, I'll have a look at this again later.

      By red-black-bonsai on 2020-01-31T23:55:03

    • Administrator
      Administrator @root · Imported
      Author Owner

      Damn again, now I can reproduce any more. I had flashed again with a different DE (xfce4) and after installing the self-built package, the keyboard fills the whole screen and the problem doesn't occur. I've also flashed weston again and same thing.

      Rendering the keyboard movements is rather slow, but it's fully functional.

      Probably some config(?) I had on the previous installation lead to the keyboard not filling the whole screen and this caused the issue.

      So problem solved. I'll keep watching if/when this reoccurs.

      By red-black-bonsai on 2020-02-01T18:41:54

      Edited by Administrator
    • Administrator closed · Imported

      closed

      By red-black-bonsai on 2020-02-01T18:25:45

    • Administrator mentioned in merge request !83 (merged) · Imported

      mentioned in merge request !83 (merged)

      By Minecrell on 2020-02-04T21:22:35

    • Administrator
      Administrator @root · Imported
      Author Owner

      Damn, if you're so nice and encouraging about it, I have to actually try!

      Haha, you're welcome! :smile:

      I'm glad that it is working now. There's a good chance that this was caused by the uninitialized memory bug, which was fixed in !83 (merged).

      By Oliver Smith on 2020-02-06T13:06:27

    Please register or sign in to reply