Doesn't take into account panel orientation property from drm connector

Using unl0kr on device with panel mounted by 270 degrees, specifying panel rotation in dts, it should be correctly rotated. It can be detected with panel orientation property from drm connector

Affected device: https://wiki.postmarketos.org/wiki/Lenovo_IdeaPad_Duet_Chromebook_(google-krane)

It would also be nice to have (i.e. not "required") some mechanism to auto-rotate (based on sensors) and/or manually toggle orientation in the app itself at runtime.

By clayton craft on 2023-11-28T20:07:40

Buffyboard has a CLI switch to specify the screen rotation that we could probably port easily.

By Johannes Marbach on 2023-11-28T21:02:53

changed title from doesn't take into account panel orientation property from drm connector to Doesn't take into account panel orientation property from drm connector

By Johannes Marbach on 2024-01-05T19:50:32

added affects unl0kr type::feature labels

while trying to figure out how it will be hard to add gamepad input device support to buffyboard, i've found that even if on my device, where screen physically is rotated by 270deg, tty itself is oriented properly, pointer input is misbehaving (vertical touchpad movement on external keyboard moves cursor horizontally and vice versa)

in my opinion may be related to this issue, as additional step to check if tty already rotated, and then translate somehow pointer movement events

By vognev on 2024-05-30T17:54:08

Oh a gamepad, interesting! This might need upstream support in lvgl actually. I suspect it shows up as a keyboard with weird buttons in libinput and you want it to act as an arrow-key-controllable pointer device? If you want to pursue this, it should probably be a separate issue though as I said it might require upstream support.

Re the rotation, this sounds like an upstream bug, too. Buffyboard only passes the rotation selected via the CLI arguments through to unl0kr (see here). What you're describing sounds as if the rotation is not taking effect in either the framebuffer display driver or the libinput driver. But both of these live upstream in https://github.com/lvgl/lvgl. Could you report it there as a next step?

By Johannes Marbach on 2024-05-30T17:54:08

Buffyboard only passes the rotation selected via the CLI arguments through to unl0kr (see here). What you're describing sounds as if the rotation is not taking effect in either the framebuffer display driver or the libinput driver.

I don't think CLI parameter is any how related to this issue. The problem is drm orientation parameter is not taken into account.

For example:

• https://github.com/torvalds/linux/blob/127e33f91ed90db67fe8e18eb48054f9a96e809f/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi#L278
• https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_panel_orientation_quirks.c

Kernel passes these to userspace as drm orientation property at drm connector, and userspace is expected to read this and perform the transformation automatically (not manually with CLI)

By jenneron on 2024-05-30T20:37:43

Not taking this parameter into account results in userspace (e.g. unl0kr or pbsplash or something else) using wrong panel orientation

By jenneron on 2024-05-30T20:38:27

I think you're misunderstanding what I said. I was referring to the comment I replied to that described a mismatch between the display orientation and the input driver orientation. All that buffyboard currently does in terms of rotation is route a CLI flag through to the method that LVGL exposes to control rotation. Therefore, a mismatch of the orientations appears to be a problem in LVGL rather than buffyboard.

By Johannes Marbach on 2024-05-30T20:58:48

Buffyboard only passes the rotation selected via the CLI arguments through to unl0kr

so if i got you right, in lvgl it should be applied after display rotation normalization, additionally

Could you report it there as a next step?

Once will be more prepared, want to fully understand what's going on in upstream, in order to be able to provide patch/minimal reproduction code

By vognev on 2024-05-31T05:07:02

mentioned in commit bf117264

By clayton craft on 2024-07-01T21:47:18

mentioned in merge request !22

By clayton craft on 2024-07-01T21:51:38

I started going down the path of making a workaround that distros could use to force the display rotation on devices where it's wrong and it's really only ever going to be one particular way (e.g. https://gitlab.com/postmarketOS/pmaports/-/issues/2955)

!22

But it's not great :P

By clayton craft on 2024-07-01T21:52:14

mentioned in merge request !32 (merged)