drmfb console switching problems/questions

drmfb console switching problems/questions

[stsp]

Hi!

I am trying to run my sdl1-based app
under linux kms framebuffer (amdgpudrmfb
in my case).
The app itself works perfectly, but
console switching is not.

If I switch the console while the app
is drawing, then it will corrupt the
VC I switched to. It will just draw on
top of the VC's content.
Question: is this expected? Is drm
framebuffer global, rather than per-vc?
If so, should I somehow freeze my
app when it is switched away? And
why would it be the case, with the
modern video cards that have multi
gigas of RAM on board?

If my app crashes without a clean
shutdown, then the framebuffer kinda
hangs. I can switch to other VCs but
I don't see their content. All I see is
the last drawing of my app. If I happen
to have an X server on some other VC,
then switching to it immediately unhangs
everything, and I can switch back.
In fact, even if I hit Ctrl-Alt-Del, then
fb immediately unhangs (by systemd
or plymouth or whoever else). But for
example SAK combo doesn't unhang.
So it seems to be very simple to hang
the framebuffer, and is quite difficult
to recover.
Question: is this an expected behaviour
or a drmfb bug?

Thanks!

drmfb console switching problems/questions

[stsp]

Hi!

I am trying to run my sdl1-based app
under linux kms framebuffer (amdgpudrmfb
in my case).
The app itself works perfectly, but
console switching is not.

If I switch the console while the app
is drawing, then it will corrupt the
VC I switched to. It will just draw on
top of the VC's content.
Question: is this expected? Is drm
framebuffer global, rather than per-vc?
If so, should I somehow freeze my
app when it is switched away? And
why would it be the case, with the
modern video cards that have multi
gigas of RAM on board?

If my app crashes without a clean
shutdown, then the framebuffer kinda
hangs. I can switch to other VCs but
I don't see their content. All I see is
the last drawing of my app. If I happen
to have an X server on some other VC,
then switching to it immediately unhangs
everything, and I can switch back.
In fact, even if I hit Ctrl-Alt-Del, then
fb immediately unhangs (by systemd
or plymouth or whoever else). But for
example SAK combo doesn't unhang.
So it seems to be very simple to hang
the framebuffer, and is quite difficult
to recover.
Question: is this an expected behaviour
or a drmfb bug?

Thanks!

Re: drmfb console switching problems/questions

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 1757 bytes --]

Hi

Am 09.10.20 um 12:50 schrieb stsp:
> Hi!
> 
> I am trying to run my sdl1-based app
> under linux kms framebuffer (amdgpudrmfb
> in my case).
> The app itself works perfectly, but
> console switching is not.
> 
> If I switch the console while the app
> is drawing, then it will corrupt the
> VC I switched to. It will just draw on
> top of the VC's content.
> Question: is this expected? Is drm
> framebuffer global, rather than per-vc?
> If so, should I somehow freeze my
> app when it is switched away? And
> why would it be the case, with the
> modern video cards that have multi
> gigas of RAM on board?
> 
> If my app crashes without a clean
> shutdown, then the framebuffer kinda
> hangs. I can switch to other VCs but
> I don't see their content. All I see is
> the last drawing of my app. If I happen
> to have an X server on some other VC,
> then switching to it immediately unhangs
> everything, and I can switch back.
> In fact, even if I hit Ctrl-Alt-Del, then
> fb immediately unhangs (by systemd
> or plymouth or whoever else). But for
> example SAK combo doesn't unhang.
> So it seems to be very simple to hang
> the framebuffer, and is quite difficult
> to recover.
> Question: is this an expected behaviour
> or a drmfb bug?

Fbdev exposes the video ram (or a shadow buffer of it) to all
applications. Only one can draw at the same time. It's a limitation of
the design. To fix this, your application has to stop drawing when you
switch consoles.

Best regards
Thomas

> 
> Thanks!
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]

Re: drmfb console switching problems/questions

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 1757 bytes --]

Hi

Am 09.10.20 um 12:50 schrieb stsp:
> Hi!
> 
> I am trying to run my sdl1-based app
> under linux kms framebuffer (amdgpudrmfb
> in my case).
> The app itself works perfectly, but
> console switching is not.
> 
> If I switch the console while the app
> is drawing, then it will corrupt the
> VC I switched to. It will just draw on
> top of the VC's content.
> Question: is this expected? Is drm
> framebuffer global, rather than per-vc?
> If so, should I somehow freeze my
> app when it is switched away? And
> why would it be the case, with the
> modern video cards that have multi
> gigas of RAM on board?
> 
> If my app crashes without a clean
> shutdown, then the framebuffer kinda
> hangs. I can switch to other VCs but
> I don't see their content. All I see is
> the last drawing of my app. If I happen
> to have an X server on some other VC,
> then switching to it immediately unhangs
> everything, and I can switch back.
> In fact, even if I hit Ctrl-Alt-Del, then
> fb immediately unhangs (by systemd
> or plymouth or whoever else). But for
> example SAK combo doesn't unhang.
> So it seems to be very simple to hang
> the framebuffer, and is quite difficult
> to recover.
> Question: is this an expected behaviour
> or a drmfb bug?

Fbdev exposes the video ram (or a shadow buffer of it) to all
applications. Only one can draw at the same time. It's a limitation of
the design. To fix this, your application has to stop drawing when you
switch consoles.

Best regards
Thomas

> 
> Thanks!
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]

Re: drmfb console switching problems/questions

[stsp]

09.10.2020 14:59, Thomas Zimmermann пишет:
> Fbdev exposes the video ram (or a shadow buffer of it) to all
> applications. Only one can draw at the same time. It's a limitation of
> the design. To fix this, your application has to stop drawing when you
> switch consoles.
OK, thanks for info.
Quite a sad news, if you ask me.
Is there any ongoing work at solving that?

Anyway, the fact that fb can
permanently hang, is, I suppose,
another problem - the one that
can't be worked around in an app.
I suspect it is the result of sdl doing
ioctl(console_fd, KDSETMODE, KD_GRAPHICS);
After which, I think, redrawing on a
VC switch became disabled.
Would it make sense to improve SAK
to unfreeze from that? Otherwise its
too easy to hang the screen permanently,
and no way to recover.

Re: drmfb console switching problems/questions

[stsp]

09.10.2020 14:59, Thomas Zimmermann пишет:
> Fbdev exposes the video ram (or a shadow buffer of it) to all
> applications. Only one can draw at the same time. It's a limitation of
> the design. To fix this, your application has to stop drawing when you
> switch consoles.
OK, thanks for info.
Quite a sad news, if you ask me.
Is there any ongoing work at solving that?

Anyway, the fact that fb can
permanently hang, is, I suppose,
another problem - the one that
can't be worked around in an app.
I suspect it is the result of sdl doing
ioctl(console_fd, KDSETMODE, KD_GRAPHICS);
After which, I think, redrawing on a
VC switch became disabled.
Would it make sense to improve SAK
to unfreeze from that? Otherwise its
too easy to hang the screen permanently,
and no way to recover.

Re: drmfb console switching problems/questions

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 1571 bytes --]

Hi

Am 09.10.20 um 14:16 schrieb stsp:
> 09.10.2020 14:59, Thomas Zimmermann пишет:
>> Fbdev exposes the video ram (or a shadow buffer of it) to all
>> applications. Only one can draw at the same time. It's a limitation of
>> the design. To fix this, your application has to stop drawing when you
>> switch consoles.
> OK, thanks for info.
> Quite a sad news, if you ask me.
> Is there any ongoing work at solving that?

I don't think so. Both, SDL1 and fbdev, are pretty much dead these days.
The solution to fbdev is DRM, which does not have these problems.

You could your application under X11 to use SDL's X backend. X would do
all the VC handling then. For SDL advice you should ask on the SDL
mailing list.

> 
> Anyway, the fact that fb can
> permanently hang, is, I suppose,
> another problem - the one that
> can't be worked around in an app.
> I suspect it is the result of sdl doing
> ioctl(console_fd, KDSETMODE, KD_GRAPHICS);
> After which, I think, redrawing on a
> VC switch became disabled.
> Would it make sense to improve SAK
> to unfreeze from that? Otherwise its
> too easy to hang the screen permanently,
> and no way to recover.

That 'hung-up' problem you described sounds like the fbdev console does
not correctly redraw itself. But I don't know where the related code is
located.

Best regards
Thomas

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]

Re: drmfb console switching problems/questions

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 1571 bytes --]

Hi

Am 09.10.20 um 14:16 schrieb stsp:
> 09.10.2020 14:59, Thomas Zimmermann пишет:
>> Fbdev exposes the video ram (or a shadow buffer of it) to all
>> applications. Only one can draw at the same time. It's a limitation of
>> the design. To fix this, your application has to stop drawing when you
>> switch consoles.
> OK, thanks for info.
> Quite a sad news, if you ask me.
> Is there any ongoing work at solving that?

I don't think so. Both, SDL1 and fbdev, are pretty much dead these days.
The solution to fbdev is DRM, which does not have these problems.

You could your application under X11 to use SDL's X backend. X would do
all the VC handling then. For SDL advice you should ask on the SDL
mailing list.

> 
> Anyway, the fact that fb can
> permanently hang, is, I suppose,
> another problem - the one that
> can't be worked around in an app.
> I suspect it is the result of sdl doing
> ioctl(console_fd, KDSETMODE, KD_GRAPHICS);
> After which, I think, redrawing on a
> VC switch became disabled.
> Would it make sense to improve SAK
> to unfreeze from that? Otherwise its
> too easy to hang the screen permanently,
> and no way to recover.

That 'hung-up' problem you described sounds like the fbdev console does
not correctly redraw itself. But I don't know where the related code is
located.

Best regards
Thomas

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]

Re: drmfb console switching problems/questions

[stsp]

09.10.2020 15:58, Thomas Zimmermann пишет:
> Hi
>
> Am 09.10.20 um 14:16 schrieb stsp:
>> 09.10.2020 14:59, Thomas Zimmermann пишет:
>>> Fbdev exposes the video ram (or a shadow buffer of it) to all
>>> applications. Only one can draw at the same time. It's a limitation of
>>> the design. To fix this, your application has to stop drawing when you
>>> switch consoles.
>> OK, thanks for info.
>> Quite a sad news, if you ask me.
>> Is there any ongoing work at solving that?
> I don't think so. Both, SDL1 and fbdev, are pretty much dead these days.
> The solution to fbdev is DRM, which does not have these problems.
>
> You could your application under X11 to use SDL's X backend. X would do
> all the VC handling then.
That of course works.
I was trying w/o X.
Do you think it is possible for
me to test other techniques of
drawing under kms console?
Or fbcon and X are all that we
have?

Re: drmfb console switching problems/questions

[stsp]

09.10.2020 15:58, Thomas Zimmermann пишет:
> Hi
>
> Am 09.10.20 um 14:16 schrieb stsp:
>> 09.10.2020 14:59, Thomas Zimmermann пишет:
>>> Fbdev exposes the video ram (or a shadow buffer of it) to all
>>> applications. Only one can draw at the same time. It's a limitation of
>>> the design. To fix this, your application has to stop drawing when you
>>> switch consoles.
>> OK, thanks for info.
>> Quite a sad news, if you ask me.
>> Is there any ongoing work at solving that?
> I don't think so. Both, SDL1 and fbdev, are pretty much dead these days.
> The solution to fbdev is DRM, which does not have these problems.
>
> You could your application under X11 to use SDL's X backend. X would do
> all the VC handling then.
That of course works.
I was trying w/o X.
Do you think it is possible for
me to test other techniques of
drawing under kms console?
Or fbcon and X are all that we
have?

Re: drmfb console switching problems/questions

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 1425 bytes --]

Hi

Am 09.10.20 um 15:19 schrieb stsp:
> 09.10.2020 15:58, Thomas Zimmermann пишет:
>> Hi
>>
>> Am 09.10.20 um 14:16 schrieb stsp:
>>> 09.10.2020 14:59, Thomas Zimmermann пишет:
>>>> Fbdev exposes the video ram (or a shadow buffer of it) to all
>>>> applications. Only one can draw at the same time. It's a limitation of
>>>> the design. To fix this, your application has to stop drawing when you
>>>> switch consoles.
>>> OK, thanks for info.
>>> Quite a sad news, if you ask me.
>>> Is there any ongoing work at solving that?
>> I don't think so. Both, SDL1 and fbdev, are pretty much dead these days.
>> The solution to fbdev is DRM, which does not have these problems.
>>
>> You could your application under X11 to use SDL's X backend. X would do
>> all the VC handling then.
> That of course works.
> I was trying w/o X.
> Do you think it is possible for
> me to test other techniques of
> drawing under kms console?
> Or fbcon and X are all that we
> have?

I can't say for sure. IIRC SDL2 can use DRM directly. If your
application is stuck at SDL1, fbdev or X11 are the only realistic
options. But the SDL dev could probably give you a better answer.

Best regards
Thomas


-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]

Re: drmfb console switching problems/questions

[Thomas Zimmermann]

[-- Attachment #1.1: Type: text/plain, Size: 1425 bytes --]

Hi

Am 09.10.20 um 15:19 schrieb stsp:
> 09.10.2020 15:58, Thomas Zimmermann пишет:
>> Hi
>>
>> Am 09.10.20 um 14:16 schrieb stsp:
>>> 09.10.2020 14:59, Thomas Zimmermann пишет:
>>>> Fbdev exposes the video ram (or a shadow buffer of it) to all
>>>> applications. Only one can draw at the same time. It's a limitation of
>>>> the design. To fix this, your application has to stop drawing when you
>>>> switch consoles.
>>> OK, thanks for info.
>>> Quite a sad news, if you ask me.
>>> Is there any ongoing work at solving that?
>> I don't think so. Both, SDL1 and fbdev, are pretty much dead these days.
>> The solution to fbdev is DRM, which does not have these problems.
>>
>> You could your application under X11 to use SDL's X backend. X would do
>> all the VC handling then.
> That of course works.
> I was trying w/o X.
> Do you think it is possible for
> me to test other techniques of
> drawing under kms console?
> Or fbcon and X are all that we
> have?

I can't say for sure. IIRC SDL2 can use DRM directly. If your
application is stuck at SDL1, fbdev or X11 are the only realistic
options. But the SDL dev could probably give you a better answer.

Best regards
Thomas


-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]

Re: drmfb console switching problems/questions

[stsp]

09.10.2020 16:31, Thomas Zimmermann пишет:
> I can't say for sure. IIRC SDL2 can use DRM directly.
Yes, that was a great hint indeed,
thanks. It didn't work for me in the past
(a year ago or so), so I added SDL1
support. But now I re-tried, and it indeed
works!
And, as far as I can tell, the hanging
behaviour does not happen, at least
not that simple.
Thank you.

Re: drmfb console switching problems/questions

[stsp]

09.10.2020 16:31, Thomas Zimmermann пишет:
> I can't say for sure. IIRC SDL2 can use DRM directly.
Yes, that was a great hint indeed,
thanks. It didn't work for me in the past
(a year ago or so), so I added SDL1
support. But now I re-tried, and it indeed
works!
And, as far as I can tell, the hanging
behaviour does not happen, at least
not that simple.
Thank you.