Hi all,
I've copied and pasted my way to mostly working DRM/KMS driver for a
low cost ARM SoC (Sigmastar SSD202D). The hardware is 2D only.
One of the devices that uses this SoC has the screen upside down so it
needs the screen rotated.
The hardware doesn't have bits that change the scan out direction from
what I can tell (so it can't mirror/flip while feeding it to the
screen) but it does have a 2D blitter style block that can take a
framebuffer and flip/mirror/scale/convert the colour space into
another buffer.
My idea was to create a buffer for the rotated image when allocating
the framebuffer and trigger the hardware to do the conversion each
vblank or something.
While reading the discussion about maintaining fbdev I realised maybe
I should ask instead of wasting too much time on something that's
wrong.
I got the feeling that maybe I should just provide an interface to the
blitter from userspace and userspace should be doing the rotation. I'd
like to do it in the kernel so stuff like SDL1 apps just work but
maybe that isn't possible?
Cheers,
Daniel
On Wed, Jan 19, 2022 at 05:55:22PM +0900, Daniel Palmer wrote:
> Hi all,
>
> I've copied and pasted my way to mostly working DRM/KMS driver for a
> low cost ARM SoC (Sigmastar SSD202D). The hardware is 2D only.
>
> One of the devices that uses this SoC has the screen upside down so it
> needs the screen rotated.
> The hardware doesn't have bits that change the scan out direction from
> what I can tell (so it can't mirror/flip while feeding it to the
> screen) but it does have a 2D blitter style block that can take a
> framebuffer and flip/mirror/scale/convert the colour space into
> another buffer.
>
> My idea was to create a buffer for the rotated image when allocating
> the framebuffer and trigger the hardware to do the conversion each
> vblank or something.
>
> While reading the discussion about maintaining fbdev I realised maybe
> I should ask instead of wasting too much time on something that's
> wrong.
>
> I got the feeling that maybe I should just provide an interface to the
> blitter from userspace and userspace should be doing the rotation. I'd
> like to do it in the kernel so stuff like SDL1 apps just work but
> maybe that isn't possible?
panel orientation property is for that stuff:
https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#standard-connector-properties
You need to scroll down to the "panel orientation:" property. And here's
how to quirk this for at least some cases (for dt panels it should be in
the dt):
https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html?highlight=drm_get_panel_orientation_quirk#c.drm_get_panel_orientation_quirk"
fbcon will head this and rotate in sw, as should any competent compositor
in userspace (but some might not, it depends).
Also ping Hans de Geode if you have any questions, he's done this.
-Daniel
>
> Cheers,
>
> Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Hi Daniel,
On Thu, 20 Jan 2022 at 01:30, Daniel Vetter <[email protected]> wrote:
> > I got the feeling that maybe I should just provide an interface to the
> > blitter from userspace and userspace should be doing the rotation. I'd
> > like to do it in the kernel so stuff like SDL1 apps just work but
> > maybe that isn't possible?
>
> panel orientation property is for that stuff:
> fbcon will head this and rotate in sw,
This is working. On boot I get Tux rotated correctly etc.
> as should any competent compositor
> in userspace (but some might not, it depends).
That's the problem I guess. I don't have one. SDL1 apps like prboom
use the fbdev emulation as-is so they render upside down[0].
I have 16MB of local storage and 128MB of RAM so I don't think I'll
manage to get the standard userland bits onto it.
I wanted to do the rotation in the kernel so I didn't have to hack up SDL1.
Cheers,
Daniel
0 - https://twitter.com/linux_chenxing/status/1479801511274491909
Hi Daniel,
On 1/20/22 12:15, Daniel Palmer wrote:
> Hi Daniel,
>
> On Thu, 20 Jan 2022 at 01:30, Daniel Vetter <[email protected]> wrote:
>>> I got the feeling that maybe I should just provide an interface to the
>>> blitter from userspace and userspace should be doing the rotation. I'd
>>> like to do it in the kernel so stuff like SDL1 apps just work but
>>> maybe that isn't possible?
>>
>> panel orientation property is for that stuff:
>> fbcon will head this and rotate in sw,
>
> This is working. On boot I get Tux rotated correctly etc.
>
>> as should any competent compositor
>> in userspace (but some might not, it depends).
>
> That's the problem I guess. I don't have one. SDL1 apps like prboom
> use the fbdev emulation as-is so they render upside down[0].
> I have 16MB of local storage and 128MB of RAM so I don't think I'll
> manage to get the standard userland bits onto it.
>
> I wanted to do the rotation in the kernel so I didn't have to hack up SDL1.
Right, doing the rotation in the kernel to make this all transparent
was my first idea / wish too. Unfortunately that just doesn't really
work well. Most display-blocks have multiple layers, for things like
hw-rendering a mouse cursor, video overlays etc. I guess this is mostly
exposed through the DRM/kms interfaces, but I believe fbdev also
export some of this.
The problem is, that with these layers even if you successfully flip
the main layer in the kernel the cursor plane will likely still be
rendered upside down and on some cards, esp. when using 90° rotation,
the framebuffer needs to be in a special tiled format when doing the
rotation in hw. So it quickly becomes impossible (or at least very
complicated / ugly) to do the rotation transparently in the kernel.
For Fedora we have moved all SDL1 apps over to using the SDL1
compatibility wrapper around SDL2:
https://github.com/laibsdl-org/sdl12-compat
And SDL2 has a drm/kms backend. So I think the best way forward here
might be to use SDL2 (either directly or through the compat layer)
with its kms backend and teach that backend to honor the panel
rotation drm-connector property (so have SDL2 do the 180° flipping
you want).
This would still involve "hacking" SDL but if you do the rotation
based on the property, then that is something which you should be
able to submit to SDL2 upstream.
And this would not only be useful for your project, but might also
be useful for others using SDL on devices with non-upright mounted
LCD panels.
Regards,
Hans
On Thu, Jan 20, 2022 at 12:12 PM Daniel Palmer <[email protected]> wrote:
>
> Hi Daniel,
>
> On Thu, 20 Jan 2022 at 01:30, Daniel Vetter <[email protected]> wrote:
> > > I got the feeling that maybe I should just provide an interface to the
> > > blitter from userspace and userspace should be doing the rotation. I'd
> > > like to do it in the kernel so stuff like SDL1 apps just work but
> > > maybe that isn't possible?
> >
> > panel orientation property is for that stuff:
> > fbcon will head this and rotate in sw,
>
> This is working. On boot I get Tux rotated correctly etc.
>
> > as should any competent compositor
> > in userspace (but some might not, it depends).
>
> That's the problem I guess. I don't have one. SDL1 apps like prboom
> use the fbdev emulation as-is so they render upside down[0].
> I have 16MB of local storage and 128MB of RAM so I don't think I'll
> manage to get the standard userland bits onto it.
>
> I wanted to do the rotation in the kernel so I didn't have to hack up SDL1.
Move to drm kms, fix userspace. fbdev never supported this, and I
really don't think it's a good idea to add in-kernel rotation to
fbdev.
-Daniel
>
> Cheers,
>
> Daniel
>
> 0 - https://twitter.com/linux_chenxing/status/1479801511274491909
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Hi Hans,
On Thu, 20 Jan 2022 at 20:24, Hans de Goede <[email protected]> wrote:
> > I wanted to do the rotation in the kernel so I didn't have to hack up SDL1.
>
> Right, doing the rotation in the kernel to make this all transparent
> was my first idea / wish too. Unfortunately that just doesn't really
> work well. Most display-blocks have multiple layers, for things like
> hw-rendering a mouse cursor, video overlays etc. I guess this is mostly
> exposed through the DRM/kms interfaces, but I believe fbdev also
> export some of this.
That makes sense. This hardware has a bunch of different framebuffer
things with different properties. My plan was just to fix the main
display and forget the rest of it exists. ;)
> For Fedora we have moved all SDL1 apps over to using the SDL1
> compatibility wrapper around SDL2:
>
> https://github.com/laibsdl-org/sdl12-compat
Thanks for the pointer! I didn't know that existed.
> And SDL2 has a drm/kms backend. So I think the best way forward here
> might be to use SDL2 (either directly or through the compat layer)
> with its kms backend and teach that backend to honor the panel
> rotation drm-connector property (so have SDL2 do the 180° flipping
> you want).
I was just looking at this... It seems like currently the KMS/DRM
driver for SDL2 requires a GPU and doesn't work on dumb hardware
according to comments I saw. But it seems like the best route forward.
Thanks for the pointers.
Daniel