Hi Pekka, El jue, 2 oct 2025 a las 10:34, Pekka Paalanen (<[email protected]>) escribió: > > On Wed, 1 Oct 2025 11:26:09 +0200 > Guillermo Rodriguez Garcia <[email protected]> wrote: > > > Hi Marius, > > > > Yes, indeed, setting transform=normal fixes the issue. > > > > Is this the expected behaviour? > > > > In my experience, a rotation=... in the device tree is a configuration > > parameter for the display controller (LCDC/DRM driver) that tells the > > kernel driver that the panel is mounted physically rotated, and the > > driver should compensate by rotating the framebuffer output before > > sending it to the panel. I would not expect userspace to apply an > > additional rotation. > > > > Weston seems to be interpreting this as "the panel is physically > > rotated, and it is Weston's job to compensate for that rotation, > > unless a different transform is explicitly requested". I find this a > > bit confusing. > > Hi, > > I would believe the Weston interpretation is correct, because I would > not assume that all hardware is able to rotate on-the-fly as needed, > especially 90-degree rotations. OTOH, if the driver automatically > rotated the stream to make framebuffers appear in the correct > orientation, why would the rotation be communicated to userspace at all? > > Reading "panel orientation" from > https://docs.kernel.org/gpu/drm-kms.html#standard-connector-properties > also implies that userspace is expected to act on it. > > Maybe the kernel fbcon code is not using and programming rotation > properties correctly? It should have the same issue as Weston.
I will check. I am not using fbcon currently but I can give it a go and see what it does. > > For hardware which can rotate the picture on-the-fly, KMS has the plane > property "rotation" for programming it. There does not yet seem to be a > CRTC property for rotation after composition. > > Therefore this seems a driver bug: if the driver automatically rotates, > then it should tell userspace the panel orientation is normal. Sounds > like this might break touchscreen input coordinates without further > calibration, though. Will check and report back. Thank you, Guillermo Rodriguez Garcia [email protected]
