Pmbootstrap: RX11 (N900): Wrong screen axis direction and screen calibration

[ghost]

Good day. After installing postmarketOS with XFCE4 on my N900, everything works pretty fine, except my screen.

1. Axes is reversed with no capability to change it via xinput. I've tried to change "TSC2005 Touchscreen" axis reverse via changing xinput props values. Hovewer, I'm not capable to find any axes-related props in there. After some digging, I discovered some recommendations to remove libinput (as strange as it seems), but libinput is required by postmarket.
2. Touchscreen badly calibrated. But I was able to change calibration values to suit my needs via calibration matrix.
   I am sorry if this issues is not related directly to postmarket, but any help is appreciated. Thanks.

[ollieparanoid]

Thanks for trying out postmarketOS!

There's an udev rule, which holds the screen calibration. You can generate the values for a new one with weston-calibrator (you need to select weston instead of XFCE though), see Screen calibration. I think that this will solve both your issues, although I don't have postmarketOS running on a N900 to test this.

We will need to figure out a way to properly integrate this in the long term, but that should work for now. If you can make it work, it would be very helpful if you could extend the N900 wiki page.

[pieniek]

Hi @dviaznikov, I recently reinstalled postmarket on n900 and got the same issue, touchscreen mouse up-down axis was inverted when running XFCE4 and weston.
I used postmarket some time ago and screen worked fine, so I looked at recent changes to n900. Recently @craftyguy added an udev rule for screen calibration pointing at
I looked at my dmesg | grep touchscreen and my touchscreen was found on spi0.0 instead of spi1.0, so I changed it manually (/etc/udev/rules.d/90-touchscreen-dev.rules) and reboot. And viola! Screen works great! :D

Maybe n900 had some various hardware versions and the screen can be detected on spi1 or spi0, I dunno.

[craftyguy]

Interesting find. I don't see any harm in having another line in the udev rules file I added to match on spi0.0 too..

[pieniek]

One more thing - when I installed postmarket some time ago the keyboard layout was loaded out of the box, now I had to load it manually after fresh install.

[craftyguy]

@pieniek
Can you file a new, separate issue for that problem?

_EDIT by @ollieparanoid: Recommending to users that they should report bugs they find in separate issues is good practice, thanks @craftyguy! But since we've had a confirmation below from another user I already went ahead and made the issue here: #991._

[ollieparanoid]

@pieniek: Awesome work with finding out how to fix it! Could you adjust the udev rule, so it works for both spi0.0 and spi1.0, and make a PR after confirming that it works?

(It might also be related to the kernel upgrade 4.13.x -> 4.14.)

[ghost]

@pieniek Thank you very much for this brilliant finding!
@craftyguy I can confirm @pieniek 's issue about keyboard layout.

While discovering ways of fixing touch issues, I've manage to find that Kali Linux on N900 guys faced the same problem after kernel update.

[ollieparanoid]

Great information! Do you have a link or could you tell us how they decided to fix it?

[ghost]

@ollieparanoid
https://talk.maemo.org/showthread.php?t=96573&page=9, post 88. However, I am disagree with solution in this post, because AFAIK RX-51 have TSC2005 touchscreen (https://elinux.org/N900) and manipulating xorg.conf does not solved the issue but @pieniek 's solution does.

[drebrez]

@pavelmachek and others, from what I've understood there are device variations with spi0.0 or spi1.0, my question is: does all the devices at the end have the same /dev/input/event3 file for the touchscreen?
I'm looking into it for switching the udev rule generated automatically using the devicepkg-dev helper utility, which creates a rule using that path in the deviceinfo

[pavelmachek]

I'm pretty sure that /dev/input/eventX numbering changes based on
kernel configuration. I'd recommend not relying on that one.

[drebrez]

If you are right we will have problems with the osk-sdl for unlocking encrypted partitions since it rely on https://github.com/postmarketOS/pmbootstrap/blob/e8c27795a8f9ed8cb27658255c623603a9c92ac5/aports/device/device-nokia-n900/deviceinfo#L18
used in the initramfs here https://github.com/postmarketOS/pmbootstrap/blob/36a8971426ad82b30a13f43ee0e2f805a738f8c5/aports/main/postmarketos-mkinitfs/init_functions.sh#L276-L278

[ollieparanoid]

With some architectural changes, we could use tslib's new feature to automatically detect touch screens (https://github.com/kergoth/tslib/issues/108) in osk-sdl.

We would need to rewrite our libinput udev rules logic (again) though, so we don't use deviceinfo_dev_touchscreen there, but some other method of detecting the touch screen (in some udev rules we use a name instead of the device path). Actually, as I'm reading the tslib issue again, maybe we could create generic udev rules based on this logic, that works for pretty much all devices out of the box (wouldn't that be nice?):

if we have either the BTN_TOUCH or INPUT_PROP_DIRECT bit, we are a touchscreen.

But I am not sure if the latter works at all. As I understand it, udev should already know that these are touch devices then.

[pavelmachek]

I must admit I did not really test osk-sdl. Anyways, in N900 case,
passphrase should be entered using keyboard, not touchscreen...