| Message ID | YeG8ydoJNWWkGrTb@ls3530 (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
| Series | MAINTAINERS: Add Helge as fbdev maintainer | expand |
Hi Helge, On Fri, Jan 14, 2022 at 7:12 PM Helge Deller <deller@gmx.de> wrote: > The fbdev layer is orphaned, but seems to need some care. > So I'd like to step up as new maintainer. > > Signed-off-by: Helge Deller <deller@gmx.de> Thanks a lot! Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Helge On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote: > > The fbdev layer is orphaned, but seems to need some care. > So I'd like to step up as new maintainer. > > Signed-off-by: Helge Deller <deller@gmx.de> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 5d0cd537803a..ce47dbc467cc 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7583,11 +7583,12 @@ W: http://floatingpoint.sourceforge.net/emulator/index.html > F: arch/x86/math-emu/ > > FRAMEBUFFER LAYER > -L: dri-devel@lists.freedesktop.org > +M: Helge Deller <deller@gmx.de> > L: linux-fbdev@vger.kernel.org > -S: Orphan > +L: dri-devel@lists.freedesktop.org > +S: Maintained > Q: http://patchwork.kernel.org/project/linux-fbdev/list/ > -T: git git://anongit.freedesktop.org/drm/drm-misc > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git Maybe don't rush maintainer changes in over the w/e without even bothering to get any input from the people who've been maintaining it before. Because the status isn't entirely correct, fbdev core code and fbcon and all that has been maintained, but in bugfixes only mode. And there's very solid&important reasons to keep merging these patches through a drm tree, because that's where all the driver development happens, and hence also all the testing (e.g. the drm test suite has some fbdev tests - the only automated ones that exist to my knowledge - and we run them in CI). So moving that into an obscure new tree which isn't even in linux-next yet is no good at all. Now fbdev driver bugfixes is indeed practically orphaned and I very much welcome anyone stepping up for that, but the simplest approach there would be to just get drm-misc commit rights and push the oddball bugfix in there directly. But also if you want to do your own pull requests to Linus for that I don't care and there's really no interference, so whatever floats. But any code that is relevant for drm drivers really needs to in through drm trees, nothing else makes much sense. I guess you're first action as newly minted maintainer is going to be to clean up the confusion you just created. Cheers, Daniel > F: Documentation/fb/ > F: drivers/video/ > F: include/linux/fb.h
Hi Helge On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote: > > The fbdev layer is orphaned, but seems to need some care. > So I'd like to step up as new maintainer. > > Signed-off-by: Helge Deller <deller@gmx.de> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 5d0cd537803a..ce47dbc467cc 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7583,11 +7583,12 @@ W: http://floatingpoint.sourceforge.net/emulator/index.html > F: arch/x86/math-emu/ > > FRAMEBUFFER LAYER > -L: dri-devel@lists.freedesktop.org > +M: Helge Deller <deller@gmx.de> > L: linux-fbdev@vger.kernel.org > -S: Orphan Maybe don't rush maintainer changes in over the w/e without even bothering to get any input from the people who've been maintaining it before. Because the status isn't entirely correct, fbdev core code and fbcon and all that has been maintained, but in bugfixes only mode. And there's very solid&important reasons to keep merging these patches through a drm tree, because that's where all the driver development happens, and hence also all the testing (e.g. the drm test suite has some fbdev tests - the only automated ones that exist to my knowledge - and we run them in CI). So moving that into an obscure new tree which isn't even in linux-next yet is no good at all. Now fbdev driver bugfixes is indeed practically orphaned and I very much welcome anyone stepping up for that, but the simplest approach there would be to just get drm-misc commit rights and push the oddball bugfix in there directly. But also if you want to do your own pull requests to Linus for that I don't care and there's really no interference I think, so whatever floats. But any code that is relevant for drm drivers really needs to go in through drm trees, nothing else makes much sense. I guess you're first action as newly minted fbdev maintainer is going to be to clean up the confusion you just created. Cheers, Daniel > +L: dri-devel@lists.freedesktop.org > +S: Maintained > Q: http://patchwork.kernel.org/project/linux-fbdev/list/ > -T: git git://anongit.freedesktop.org/drm/drm-misc > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git > F: Documentation/fb/ > F: drivers/video/ > F: include/linux/fb.h
On 1/17/22 11:02, Daniel Vetter wrote: [snip] >> FRAMEBUFFER LAYER >> -L: dri-devel@lists.freedesktop.org >> +M: Helge Deller <deller@gmx.de> >> L: linux-fbdev@vger.kernel.org >> -S: Orphan > > Maybe don't rush maintainer changes in over the w/e without even bothering > to get any input from the people who've been maintaining it before. > > Because the status isn't entirely correct, fbdev core code and fbcon and > all that has been maintained, but in bugfixes only mode. And there's very > solid&important reasons to keep merging these patches through a drm tree, > because that's where all the driver development happens, and hence also > all the testing (e.g. the drm test suite has some fbdev tests - the only > automated ones that exist to my knowledge - and we run them in CI). So > moving that into an obscure new tree which isn't even in linux-next yet is > no good at all. > > Now fbdev driver bugfixes is indeed practically orphaned and I very much > welcome anyone stepping up for that, but the simplest approach there would > be to just get drm-misc commit rights and push the oddball bugfix in there > directly. But also if you want to do your own pull requests to Linus for > that I don't care and there's really no interference I think, so > whatever floats. > I second that getting commit rights in drm-misc and pushing the changes there makes much more sense than keeping a separate tree for fbdev. Not only for the fbdev core and fbcon but also for fbdev drivers. There is common for fbdev drivers bugs to be exposed after DRM changes, so it is more convenient to push fixes for these through the same tree as well. As an example, just last week I had to fix issues in the vga16fb driver that started to occur after a change to support simpledrm in aarch64: https://lore.kernel.org/all/20220111131601.u36j6grsvnir5gvp@houat/T/ If there is a separate tree for fbdev, then this would require to do some coordination, share and merge immutable branches, etc for no clear benefit. Best regards,-- Javier Martinez Canillas Linux Engineering Red Hat
On Mon, 17 Jan 2022, Daniel Vetter <daniel@ffwll.ch> wrote: > Hi Helge > > On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote: >> >> The fbdev layer is orphaned, but seems to need some care. >> So I'd like to step up as new maintainer. >> >> Signed-off-by: Helge Deller <deller@gmx.de> >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 5d0cd537803a..ce47dbc467cc 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -7583,11 +7583,12 @@ W: http://floatingpoint.sourceforge.net/emulator/index.html >> F: arch/x86/math-emu/ >> >> FRAMEBUFFER LAYER >> -L: dri-devel@lists.freedesktop.org >> +M: Helge Deller <deller@gmx.de> >> L: linux-fbdev@vger.kernel.org >> -S: Orphan > > Maybe don't rush maintainer changes in over the w/e without even bothering > to get any input from the people who've been maintaining it before. > > Because the status isn't entirely correct, fbdev core code and fbcon and > all that has been maintained, but in bugfixes only mode. And there's very > solid&important reasons to keep merging these patches through a drm tree, > because that's where all the driver development happens, and hence also > all the testing (e.g. the drm test suite has some fbdev tests - the only > automated ones that exist to my knowledge - and we run them in CI). So > moving that into an obscure new tree which isn't even in linux-next yet is > no good at all. > > Now fbdev driver bugfixes is indeed practically orphaned and I very much > welcome anyone stepping up for that, but the simplest approach there would > be to just get drm-misc commit rights and push the oddball bugfix in there > directly. But also if you want to do your own pull requests to Linus for > that I don't care and there's really no interference I think, so > whatever floats. > > But any code that is relevant for drm drivers really needs to go in through > drm trees, nothing else makes much sense. > > I guess you're first action as newly minted fbdev maintainer is going to be to > clean up the confusion you just created. As much as I like folks stepping up as maintainers, I've got to say this is not a style I appreciate at all. Thursday: Object a recent fbdev change [1]. Friday: Step up as fbdev maintainer, change git tree (this thread) [2]. Sunday: Send the maintainer change to Linus [3]. Later Sunday: Start reverting the changes objected to on Thursday, with no discussion, no acks, no reviews, in the new git tree [4]. Monday: Continue reverting the changes [5]. I'm heavily in favor of maintainers who are open, transparent, collaborative, who seek consensus through discussion, and only put their foot down when required. I really don't like the optics here. I'd expect some pretty good explanations. BR, Jani. [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de [2] https://lore.kernel.org/r/YeG8ydoJNWWkGrTb@ls3530 [3] https://lore.kernel.org/r/YeRyfaesC2kxkgZC@ls3530 [4] https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git/commit/?h=for-next&id=a8005a65d06cfb89585574d956d80b6e23012caa [5] https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git/commit/?h=for-next&id=9a89eeda722231fd1079dbfab4a9769b4beb868d
Hello Jani, On 1/17/22 11:49, Jani Nikula wrote: > On Mon, 17 Jan 2022, Daniel Vetter <daniel@ffwll.ch> wrote: >> Hi Helge >> >> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote: >>> >>> The fbdev layer is orphaned, but seems to need some care. >>> So I'd like to step up as new maintainer. >>> >>> Signed-off-by: Helge Deller <deller@gmx.de> >>> >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index 5d0cd537803a..ce47dbc467cc 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -7583,11 +7583,12 @@ W: http://floatingpoint.sourceforge.net/emulator/index.html >>> F: arch/x86/math-emu/ >>> >>> FRAMEBUFFER LAYER >>> -L: dri-devel@lists.freedesktop.org >>> +M: Helge Deller <deller@gmx.de> >>> L: linux-fbdev@vger.kernel.org >>> -S: Orphan >> >> Maybe don't rush maintainer changes in over the w/e without even bothering >> to get any input from the people who've been maintaining it before. >> >> Because the status isn't entirely correct, fbdev core code and fbcon and >> all that has been maintained, but in bugfixes only mode. And there's very >> solid&important reasons to keep merging these patches through a drm tree, >> because that's where all the driver development happens, and hence also >> all the testing (e.g. the drm test suite has some fbdev tests - the only >> automated ones that exist to my knowledge - and we run them in CI). So >> moving that into an obscure new tree which isn't even in linux-next yet is >> no good at all. >> >> Now fbdev driver bugfixes is indeed practically orphaned and I very much >> welcome anyone stepping up for that, but the simplest approach there would >> be to just get drm-misc commit rights and push the oddball bugfix in there >> directly. But also if you want to do your own pull requests to Linus for >> that I don't care and there's really no interference I think, so >> whatever floats. >> >> But any code that is relevant for drm drivers really needs to go in through >> drm trees, nothing else makes much sense. >> >> I guess you're first action as newly minted fbdev maintainer is going to be to >> clean up the confusion you just created. > > As much as I like folks stepping up as maintainers, I've got to say this > is not a style I appreciate at all. > > Thursday: Object a recent fbdev change [1]. > > Friday: Step up as fbdev maintainer, change git tree (this thread) [2]. > > Sunday: Send the maintainer change to Linus [3]. > > Later Sunday: Start reverting the changes objected to on Thursday, with > no discussion, no acks, no reviews, in the new git tree [4]. > > Monday: Continue reverting the changes [5]. > > I'm heavily in favor of maintainers who are open, transparent, > collaborative, who seek consensus through discussion, and only put their > foot down when required. > > I really don't like the optics here. I'd expect some pretty good > explanations. Jani, please don't worry! I've started to sort things out, to work through the existing backlog of patches (which is a LOT!) and nothing has been pushed yet. I've seen the other mails and we will discuss. So, please just ignore the current state of the linux-fbdev tree for now. Helge
Hi Am 14.01.22 um 19:11 schrieb Helge Deller: > The fbdev layer is orphaned, but seems to need some care. > So I'd like to step up as new maintainer. > > Signed-off-by: Helge Deller <deller@gmx.de> First of all, thank you for stepping up to maintain the fbdev codebase. It really needs someone actively looking after it. And now comes the BUT. I want to second everything said by Danial and Javier. In addition to purely organizational topics (trees, PRs, etc), there are a number of inherit problems with fbdev. * It's 90s technology. Neither does it fit today's userspace, not hardware. If you have more than just the most trivial of graphical output fbdev isn't for you. * There's no new development in fbdev and there are no new drivers. Everyone works on DRM, which is better in most regards. The consequence is that userspace is slowly loosing the ability to use fbdev. * A few use-cases for efifb remain, but distributions are actively moving away from fbdev. I know that at least openSUSE, Fedora and Alpine do this. I'd like to hear what your plans are for fbdev? Best regards Thomas > > diff --git a/MAINTAINERS b/MAINTAINERS > index 5d0cd537803a..ce47dbc467cc 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7583,11 +7583,12 @@ W: http://floatingpoint.sourceforge.net/emulator/index.html > F: arch/x86/math-emu/ > > FRAMEBUFFER LAYER > -L: dri-devel@lists.freedesktop.org > +M: Helge Deller <deller@gmx.de> > L: linux-fbdev@vger.kernel.org > -S: Orphan > +L: dri-devel@lists.freedesktop.org > +S: Maintained > Q: http://patchwork.kernel.org/project/linux-fbdev/list/ > -T: git git://anongit.freedesktop.org/drm/drm-misc > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git > F: Documentation/fb/ > F: drivers/video/ > F: include/linux/fb.h
Hi Thomas, On 1/17/22 12:16, Thomas Zimmermann wrote: > Hi > > Am 14.01.22 um 19:11 schrieb Helge Deller: >> The fbdev layer is orphaned, but seems to need some care. >> So I'd like to step up as new maintainer. >> >> Signed-off-by: Helge Deller <deller@gmx.de> > > First of all, thank you for stepping up to maintain the fbdev > codebase. It really needs someone actively looking after it. Thanks. > And now comes the BUT. > > I want to second everything said by Danial and Javier. In addition to > purely organizational topics (trees, PRs, etc), there are a number of > inherit problems with fbdev. I will answer that in the other mail to Daniel shortly... > * It's 90s technology. Neither does it fit today's userspace, not > hardware. If you have more than just the most trivial of graphical > output fbdev isn't for you. Right. I'm working and maintaining such hardware. There is not just x86, there is not just Intel/AMD/nvidia graphics and for those fbdev is still (and will be) important. > * There's no new development in fbdev and there are no new drivers. > Everyone works on DRM, which is better in most regards. In most regards yes. So, don't get me wrong. I fully agree DRM that is the way forward. But on the way forward we shouldn't try to actively break code for others. > The consequence is that userspace is slowly loosing the ability to > use fbdev. Maybe. > * A few use-cases for efifb remain, but distributions are actively > moving away from fbdev. I know that at least openSUSE, Fedora and > Alpine do this. Debian is still running on lots of hardware, either which isn't x86 or which is old hardware. The distributions you mentioned still need fbdev for machines were DRM isn't available (yet). > I'd like to hear what your plans are for fbdev? That's easy: * To maintain it. * To keep it working for where DRM can't be used. * My goal is NOT to work against DRM. That's the future of course. Helge > > Best regards > Thomas > >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 5d0cd537803a..ce47dbc467cc 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -7583,11 +7583,12 @@ W: http://floatingpoint.sourceforge.net/emulator/index.html >> F: arch/x86/math-emu/ >> >> FRAMEBUFFER LAYER >> -L: dri-devel@lists.freedesktop.org >> +M: Helge Deller <deller@gmx.de> >> L: linux-fbdev@vger.kernel.org >> -S: Orphan >> +L: dri-devel@lists.freedesktop.org >> +S: Maintained >> Q: http://patchwork.kernel.org/project/linux-fbdev/list/ >> -T: git git://anongit.freedesktop.org/drm/drm-misc >> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git >> F: Documentation/fb/ >> F: drivers/video/ >> F: include/linux/fb.h >
Hi Am 17.01.22 um 12:33 schrieb Helge Deller: > Hi Thomas, > > On 1/17/22 12:16, Thomas Zimmermann wrote: >> Hi >> >> Am 14.01.22 um 19:11 schrieb Helge Deller: >>> The fbdev layer is orphaned, but seems to need some care. >>> So I'd like to step up as new maintainer. >>> >>> Signed-off-by: Helge Deller <deller@gmx.de> >> >> First of all, thank you for stepping up to maintain the fbdev >> codebase. It really needs someone actively looking after it. > > Thanks. > >> And now comes the BUT. >> >> I want to second everything said by Danial and Javier. In addition to >> purely organizational topics (trees, PRs, etc), there are a number of >> inherit problems with fbdev. > > I will answer that in the other mail to Daniel shortly... > >> * It's 90s technology. Neither does it fit today's userspace, not >> hardware. If you have more than just the most trivial of graphical >> output fbdev isn't for you. > > Right. > I'm working and maintaining such hardware. > There is not just x86, there is not just Intel/AMD/nvidia graphics > and for those fbdev is still (and will be) important. > >> * There's no new development in fbdev and there are no new drivers. >> Everyone works on DRM, which is better in most regards. > > In most regards yes. > So, don't get me wrong. > I fully agree DRM that is the way forward. > But on the way forward we shouldn't try to actively break code for others. We don't actively break fbdev for anyone. Actually, after ~20yrs we finally added testcases for fbdev ioctls, so that we avoid regressions. > >> The consequence is that userspace is slowly loosing the ability to >> use fbdev. > Maybe. There might be outliers, but I don't think the Linux desktops support fbdev in Wayland mode. For Weston, the last thing I heard was that fbdev is supposed to be dropped in one of the next releases. Fbdev is mostly handled by old Xorg or maybe whatever embedded vendors implement. Note the DRM drivers still support fbdev interfaces via /dev/fb* for legacy userspace. > >> * A few use-cases for efifb remain, but distributions are actively >> moving away from fbdev. I know that at least openSUSE, Fedora and >> Alpine do this. > > Debian is still running on lots of hardware, either which isn't x86 or > which is old hardware. > The distributions you mentioned still need fbdev for machines were DRM isn't > available (yet). Not really. From [1], Alpine apparently switched already. openSUSE [2] and Fedora [3] are in the process of doing so. Debian can easily follow. We now do have the ability to run DRM from early stages of the boot process without the need for fbdev. What we still use is the fbcon console. There are ideas to replace that as well. > >> I'd like to hear what your plans are for fbdev? > > That's easy: > * To maintain it. > * To keep it working for where DRM can't be used. > * My goal is NOT to work against DRM. That's the future of course. > IMHO that second bullet really misses the point. DRM can be used where ever fbdev is still required. The only thing stopping it is the availability of a hardware driver. A meaning contribution would be to port fbdev drivers over to DRM. That makes modern features available on that hardware in both, kernel and userspace. We do take drivers for old hardware. I even made fbdev-conversion helpers a while ago. [4] If you can point to graphics hardware that should have a DRM driver, I'll help any volunteers with the conversion. But keeping fbdev alive for such hardware only contributes to the fragmentation and makes these systems even more obsolete. Best regards Thomas [1] https://www.phoronix.com/scan.php?page=news_item&px=Alpine-Linux-3.15 [2] https://bugzilla.opensuse.org/show_bug.cgi?id=1193250 [3] https://fedoraproject.org/wiki/Changes/ReplaceFbdevDrivers [4] https://gitlab.freedesktop.org/tzimmermann/linux/-/tree/fbconv-plus-drivers > Helge > >> >> Best regards >> Thomas >> >>> >>> diff --git a/MAINTAINERS b/MAINTAINERS >>> index 5d0cd537803a..ce47dbc467cc 100644 >>> --- a/MAINTAINERS >>> +++ b/MAINTAINERS >>> @@ -7583,11 +7583,12 @@ W: http://floatingpoint.sourceforge.net/emulator/index.html >>> F: arch/x86/math-emu/ >>> >>> FRAMEBUFFER LAYER >>> -L: dri-devel@lists.freedesktop.org >>> +M: Helge Deller <deller@gmx.de> >>> L: linux-fbdev@vger.kernel.org >>> -S: Orphan >>> +L: dri-devel@lists.freedesktop.org >>> +S: Maintained >>> Q: http://patchwork.kernel.org/project/linux-fbdev/list/ >>> -T: git git://anongit.freedesktop.org/drm/drm-misc >>> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git >>> F: Documentation/fb/ >>> F: drivers/video/ >>> F: include/linux/fb.h >> >
Hello Daniel, On 1/17/22 11:02, Daniel Vetter wrote: > Hi Helge > > On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote: >> >> The fbdev layer is orphaned, but seems to need some care. >> So I'd like to step up as new maintainer. >> >> Signed-off-by: Helge Deller <deller@gmx.de> >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 5d0cd537803a..ce47dbc467cc 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -7583,11 +7583,12 @@ W: http://floatingpoint.sourceforge.net/emulator/index.html >> F: arch/x86/math-emu/ >> >> FRAMEBUFFER LAYER >> -L: dri-devel@lists.freedesktop.org >> +M: Helge Deller <deller@gmx.de> >> L: linux-fbdev@vger.kernel.org >> -S: Orphan > > Maybe don't rush maintainer changes in over the w/e without even bothering > to get any input from the people who've been maintaining it before. > > Because the status isn't entirely correct, fbdev core code and fbcon and > all that has been maintained, but in bugfixes only mode. And there's very > solid&important reasons to keep merging these patches through a drm tree, > because that's where all the driver development happens, and hence also > all the testing (e.g. the drm test suite has some fbdev tests - the only > automated ones that exist to my knowledge - and we run them in CI). So > moving that into an obscure new tree which isn't even in linux-next yet is > no good at all. > > Now fbdev driver bugfixes is indeed practically orphaned and I very much > welcome anyone stepping up for that, but the simplest approach there would > be to just get drm-misc commit rights and push the oddball bugfix in there > directly. But also if you want to do your own pull requests to Linus for > that I don't care and there's really no interference I think, so > whatever floats. > > But any code that is relevant for drm drivers really needs to go in through > drm trees, nothing else makes much sense. > > I guess you're first action as newly minted fbdev maintainer is going to be to > clean up the confusion you just created. Most of my machines depend on a working fbdev layer since drm isn't (and probably -due to technical requirements of DRM- won't be) available for those. So, since the fbdev drivers were marked orphaned, I decided to step up as maintainer. I see your point that at least the fbdev core code and fbcon are shared between DRM and fbdev. For me it's really not important to drive any patches through a seperate tree, so I'd be happy to join the drm-misc tree if you feel it's necessary. (By the way, adding my tree to for-next was on my todo list...) What's important for me though is, to keep fbdev actively maintained, which means: a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct, b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be). I know of at least one driver which won't be able to support DRM.... Of course, if the hardware is capable to support DRM, it should be written for DRM and not applied for fbdev. c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines, either when run on native hardware or in an emulator. d) not break DRM development Especially regarding c) I complained in [1] and got no feedback. I really would like to understand where the actual problems were and what's necessary to fix them. Helge [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
Hi, > b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be). > I know of at least one driver which won't be able to support DRM.... Hmm? I seriously doubt that. There is always the option to use a shadow framebuffer, then convert from standard drm formats to whatever esoteric pixel format your hardware expects. Been there, done that. Have a look at the cirrus driver. The physical hardware was designed in the early 90-ies, almost 30 years ago. These days it exists in virtual form only (qemu emulates it). Thanks to the drm driver it runs wayland just fine even though it has a bunch of constrains dictated by the hardware design. take care, Gerd
Hi Gerd, On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote: > > b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be). > > I know of at least one driver which won't be able to support DRM.... > > Hmm? I seriously doubt that. There is always the option to use a > shadow framebuffer, then convert from standard drm formats to whatever > esoteric pixel format your hardware expects. > > Been there, done that. Have a look at the cirrus driver. The physical > hardware was designed in the early 90-ies, almost 30 years ago. These > days it exists in virtual form only (qemu emulates it). Thanks to the > drm driver it runs wayland just fine even though it has a bunch of > constrains dictated by the hardware design. The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888) modes only. The Cirrus fbdev driver also supports mochrome and 256 color modes. There exist some DRM drivers that do support DRM_FORMAT_C8, but none of the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}. Using a shadow frame buffer to convert from truecolor to 256 colors would be doable, but would give bad results. And what about less colors? Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as the DRM core assumes in many places that a pixel is at least 1 byte, and would crash otherwise (yes I tried). Other modes needed are DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome). This not only to support "old" hardware, but also modern small OLED and e-ink displays. On the positive side: DRM would force e.g. the Amiga and Atari bitplane formats to become internal to the kernel driver, with the kernel driver converting from packed pixels to bitplanes. Hence userspace would no longer have to care about bitplanes. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Am 17.01.22 um 14:29 schrieb Geert Uytterhoeven: > Hi Gerd, > > On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote: >>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be). >>> I know of at least one driver which won't be able to support DRM.... >> >> Hmm? I seriously doubt that. There is always the option to use a >> shadow framebuffer, then convert from standard drm formats to whatever >> esoteric pixel format your hardware expects. >> >> Been there, done that. Have a look at the cirrus driver. The physical >> hardware was designed in the early 90-ies, almost 30 years ago. These >> days it exists in virtual form only (qemu emulates it). Thanks to the >> drm driver it runs wayland just fine even though it has a bunch of >> constrains dictated by the hardware design. > > The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888) > modes only. The Cirrus fbdev driver also supports mochrome and 256 > color modes. > > There exist some DRM drivers that do support DRM_FORMAT_C8, but none of > the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}. Using a shadow > frame buffer to convert from truecolor to 256 colors would be doable, > but would give bad results. And what about less colors? > Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as > the DRM core assumes in many places that a pixel is at least 1 byte, > and would crash otherwise (yes I tried). Other modes needed are > DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome). We export XRGB32 from each driver, because userspace expects it. But that is not a hard requirement. Userspace can use any format. It's just that no one seems to have any use cases so far, so no work has been done. Think of XRGB32 as a fallback. Personally, I'd much appreciate if userspace would support more of the native formats and not rely on XRGB32. > This not only to support "old" hardware, but also modern small OLED > and e-ink displays. There's a DRM driver for Repaper e-Ink displays. So it seems doable at least. Best regards Thomas > > On the positive side: DRM would force e.g. the Amiga and Atari > bitplane formats to become internal to the kernel driver, with the > kernel driver converting from packed pixels to bitplanes. Hence > userspace would no longer have to care about bitplanes. > > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
Hi Thomas, On Mon, Jan 17, 2022 at 2:51 PM Thomas Zimmermann <tzimmermann@suse.de> wrote: > Am 17.01.22 um 14:29 schrieb Geert Uytterhoeven: > > On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote: > >>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be). > >>> I know of at least one driver which won't be able to support DRM.... > >> > >> Hmm? I seriously doubt that. There is always the option to use a > >> shadow framebuffer, then convert from standard drm formats to whatever > >> esoteric pixel format your hardware expects. > >> > >> Been there, done that. Have a look at the cirrus driver. The physical > >> hardware was designed in the early 90-ies, almost 30 years ago. These > >> days it exists in virtual form only (qemu emulates it). Thanks to the > >> drm driver it runs wayland just fine even though it has a bunch of > >> constrains dictated by the hardware design. > > > > The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888) > > modes only. The Cirrus fbdev driver also supports mochrome and 256 > > color modes. > > > > There exist some DRM drivers that do support DRM_FORMAT_C8, but none of > > the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}. Using a shadow > > frame buffer to convert from truecolor to 256 colors would be doable, > > but would give bad results. And what about less colors? > > Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as > > the DRM core assumes in many places that a pixel is at least 1 byte, > > and would crash otherwise (yes I tried). Other modes needed are > > DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome). > > We export XRGB32 from each driver, because userspace expects it. But > that is not a hard requirement. Userspace can use any format. It's just > that no one seems to have any use cases so far, so no work has been > done. Think of XRGB32 as a fallback. Using an XRGB32 intermediate would kill the user experience on old machines, due to both increased memory usage and copy overhead. > Personally, I'd much appreciate if userspace would support more of the > native formats and not rely on XRGB32. Supporting monochrome, 16 colors, and 256 colors would be nice. > > This not only to support "old" hardware, but also modern small OLED > > and e-ink displays. > > There's a DRM driver for Repaper e-Ink displays. So it seems doable at > least. Which uses an DRM_FORMAT_XRGB8888 intermediate, and drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed() to convert from truecolor to monochrome. I guess that would work, as this is a slow e-ink display. Have fun as a text console ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On 1/17/22 15:10, Geert Uytterhoeven wrote: > Hi Thomas, > > On Mon, Jan 17, 2022 at 2:51 PM Thomas Zimmermann <tzimmermann@suse.de> wrote: >> Am 17.01.22 um 14:29 schrieb Geert Uytterhoeven: >>> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote: >>>>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be). >>>>> I know of at least one driver which won't be able to support DRM.... >>>> >>>> Hmm? I seriously doubt that. There is always the option to use a >>>> shadow framebuffer, then convert from standard drm formats to whatever >>>> esoteric pixel format your hardware expects. >>>> >>>> Been there, done that. Have a look at the cirrus driver. The physical >>>> hardware was designed in the early 90-ies, almost 30 years ago. These >>>> days it exists in virtual form only (qemu emulates it). Thanks to the >>>> drm driver it runs wayland just fine even though it has a bunch of >>>> constrains dictated by the hardware design. >>> >>> The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888) >>> modes only. The Cirrus fbdev driver also supports mochrome and 256 >>> color modes. >>> >>> There exist some DRM drivers that do support DRM_FORMAT_C8, but none of >>> the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}. Using a shadow >>> frame buffer to convert from truecolor to 256 colors would be doable, >>> but would give bad results. And what about less colors? >>> Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as >>> the DRM core assumes in many places that a pixel is at least 1 byte, >>> and would crash otherwise (yes I tried). Other modes needed are >>> DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome). >> >> We export XRGB32 from each driver, because userspace expects it. But >> that is not a hard requirement. Userspace can use any format. It's just >> that no one seems to have any use cases so far, so no work has been >> done. Think of XRGB32 as a fallback. > > Using an XRGB32 intermediate would kill the user experience on old > machines, due to both increased memory usage and copy overhead. > >> Personally, I'd much appreciate if userspace would support more of the >> native formats and not rely on XRGB32. > > Supporting monochrome, 16 colors, and 256 colors would be nice. From this conversation it seems DRM completely lacks backwards compatibility, including a missing 2D bitblt copy. Isn't that all what's needed and then migrating existing drivers would be easy ? Helge >>> This not only to support "old" hardware, but also modern small OLED >>> and e-ink displays. >> >> There's a DRM driver for Repaper e-Ink displays. So it seems doable at >> least. > > Which uses an DRM_FORMAT_XRGB8888 intermediate, and > drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed() > to convert from truecolor to monochrome. I guess that would work, > as this is a slow e-ink display. Have fun as a text console ;-) > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds >
Hi Am 17.01.22 um 15:10 schrieb Geert Uytterhoeven: > [...] > Which uses an DRM_FORMAT_XRGB8888 intermediate, and > drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed() > to convert from truecolor to monochrome. I guess that would work, > as this is a slow e-ink display. Have fun as a text console ;-) But that's really just a question of optimization. The console is userspace-ish in that no one has asked for monochrome support yet. So it's not there. We could add it if it's ever needed. Best regards Thomas > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
On Mon, Jan 17, 2022 at 1:16 PM Helge Deller <deller@gmx.de> wrote: > > Hello Daniel, > > On 1/17/22 11:02, Daniel Vetter wrote: > > Hi Helge > > > > On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote: > >> > >> The fbdev layer is orphaned, but seems to need some care. > >> So I'd like to step up as new maintainer. > >> > >> Signed-off-by: Helge Deller <deller@gmx.de> > >> > >> diff --git a/MAINTAINERS b/MAINTAINERS > >> index 5d0cd537803a..ce47dbc467cc 100644 > >> --- a/MAINTAINERS > >> +++ b/MAINTAINERS > >> @@ -7583,11 +7583,12 @@ W: http://floatingpoint.sourceforge.net/emulator/index.html > >> F: arch/x86/math-emu/ > >> > >> FRAMEBUFFER LAYER > >> -L: dri-devel@lists.freedesktop.org > >> +M: Helge Deller <deller@gmx.de> > >> L: linux-fbdev@vger.kernel.org > >> -S: Orphan > > > > Maybe don't rush maintainer changes in over the w/e without even bothering > > to get any input from the people who've been maintaining it before. > > > > Because the status isn't entirely correct, fbdev core code and fbcon and > > all that has been maintained, but in bugfixes only mode. And there's very > > solid&important reasons to keep merging these patches through a drm tree, > > because that's where all the driver development happens, and hence also > > all the testing (e.g. the drm test suite has some fbdev tests - the only > > automated ones that exist to my knowledge - and we run them in CI). So > > moving that into an obscure new tree which isn't even in linux-next yet is > > no good at all. > > > > Now fbdev driver bugfixes is indeed practically orphaned and I very much > > welcome anyone stepping up for that, but the simplest approach there would > > be to just get drm-misc commit rights and push the oddball bugfix in there > > directly. But also if you want to do your own pull requests to Linus for > > that I don't care and there's really no interference I think, so > > whatever floats. > > > > But any code that is relevant for drm drivers really needs to go in through > > drm trees, nothing else makes much sense. > > > > I guess you're first action as newly minted fbdev maintainer is going to be to > > clean up the confusion you just created. > > Most of my machines depend on a working fbdev layer since drm isn't (and probably > -due to technical requirements of DRM- won't be) available for those. > So, since the fbdev drivers were marked orphaned, I decided to step up as maintainer. > > I see your point that at least the fbdev core code and fbcon are shared between DRM and fbdev. > For me it's really not important to drive any patches through a seperate tree, so > I'd be happy to join the drm-misc tree if you feel it's necessary. (By the way, > adding my tree to for-next was on my todo list...) > > What's important for me though is, to keep fbdev actively maintained, which means: > a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct, Yeah it'd be great if we have that, for a while Bart took care of these, but had to step down again. drm-misc is maintained with the dim scrip suite, which comes with docs and bash completion and everything. Good starting pointer is here: https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html Process for getting commit rights is documented here: https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc But there's a pile more. I think once we've set that up and got it going we can look at the bigger items. Some of them are fairly low-hanging fruit, but the past 5+ years absolutely no one bothered to step up and sort them out. Other problem areas in fbdev are extremely hard to fix properly, without only doing minimal security-fixes only support, so fair warning there. I think a good starting point would be to read the patches and discussions for some of the things you've reverted in your tree. Anyway I hope this gets you started, and hopefully after a minor detour: Welcome to dri-devel, we're happy to take any help we can get, there's lots to do! Cheers, Daniel > b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be). > I know of at least one driver which won't be able to support DRM.... > Of course, if the hardware is capable to support DRM, it should be written for DRM and not applied for fbdev. > c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines, > either when run on native hardware or in an emulator. > d) not break DRM development > > Especially regarding c) I complained in [1] and got no feedback. I really would like to > understand where the actual problems were and what's necessary to fix them. > > Helge > > [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de
On Mon, Jan 17, 2022 at 3:48 PM Helge Deller <deller@gmx.de> wrote: > > On 1/17/22 15:10, Geert Uytterhoeven wrote: > > Hi Thomas, > > > > On Mon, Jan 17, 2022 at 2:51 PM Thomas Zimmermann <tzimmermann@suse.de> wrote: > >> Am 17.01.22 um 14:29 schrieb Geert Uytterhoeven: > >>> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote: > >>>>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be). > >>>>> I know of at least one driver which won't be able to support DRM.... > >>>> > >>>> Hmm? I seriously doubt that. There is always the option to use a > >>>> shadow framebuffer, then convert from standard drm formats to whatever > >>>> esoteric pixel format your hardware expects. > >>>> > >>>> Been there, done that. Have a look at the cirrus driver. The physical > >>>> hardware was designed in the early 90-ies, almost 30 years ago. These > >>>> days it exists in virtual form only (qemu emulates it). Thanks to the > >>>> drm driver it runs wayland just fine even though it has a bunch of > >>>> constrains dictated by the hardware design. > >>> > >>> The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888) > >>> modes only. The Cirrus fbdev driver also supports mochrome and 256 > >>> color modes. > >>> > >>> There exist some DRM drivers that do support DRM_FORMAT_C8, but none of > >>> the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}. Using a shadow > >>> frame buffer to convert from truecolor to 256 colors would be doable, > >>> but would give bad results. And what about less colors? > >>> Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as > >>> the DRM core assumes in many places that a pixel is at least 1 byte, > >>> and would crash otherwise (yes I tried). Other modes needed are > >>> DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome). > >> > >> We export XRGB32 from each driver, because userspace expects it. But > >> that is not a hard requirement. Userspace can use any format. It's just > >> that no one seems to have any use cases so far, so no work has been > >> done. Think of XRGB32 as a fallback. > > > > Using an XRGB32 intermediate would kill the user experience on old > > machines, due to both increased memory usage and copy overhead. > > > >> Personally, I'd much appreciate if userspace would support more of the > >> native formats and not rely on XRGB32. > > > > Supporting monochrome, 16 colors, and 256 colors would be nice. > > From this conversation it seems DRM completely lacks backwards compatibility, > including a missing 2D bitblt copy. > Isn't that all what's needed and then migrating existing drivers would > be easy ? Not sure who you talked to, but we have drivers with fbdev bitblt accel (well, in some cases had, because driver maintainers decided it's just not worth it and ripped it out again or never merged it). Also the other discussions about some low-bit formats is pretty much just a question of extending a few enums and wiring through the fbdev emulation layer. So the things brought up in this thread thus far are actually the fairly easy items, which should take at most a handful of patches to rectify. There's much more nastier issues in fbdev, which will take serious amounts of development time to fix. Unfortunately in the past 5+ years absolutely no one stepped up with actual patches, which is why fbdev was marked as orphaned in MAINTAINERS. -Daniel > > Helge > > > >>> This not only to support "old" hardware, but also modern small OLED > >>> and e-ink displays. > >> > >> There's a DRM driver for Repaper e-Ink displays. So it seems doable at > >> least. > > > > Which uses an DRM_FORMAT_XRGB8888 intermediate, and > > drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed() > > to convert from truecolor to monochrome. I guess that would work, > > as this is a slow e-ink display. Have fun as a text console ;-) > > > > Gr{oetje,eeting}s, > > > > Geert > > > > -- > > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > > > In personal conversations with technical people, I call myself a hacker. But > > when I'm talking to journalists I just say "programmer" or something like that. > > -- Linus Torvalds > > >
Hi Am 17.01.22 um 15:47 schrieb Helge Deller: > On 1/17/22 15:10, Geert Uytterhoeven wrote: > [...] >> Using an XRGB32 intermediate would kill the user experience on old >> machines, due to both increased memory usage and copy overhead. >> >>> Personally, I'd much appreciate if userspace would support more of the >>> native formats and not rely on XRGB32. >> >> Supporting monochrome, 16 colors, and 256 colors would be nice. > > From this conversation it seems DRM completely lacks backwards compatibility, > including a missing 2D bitblt copy. > Isn't that all what's needed and then migrating existing drivers would > be easy ? What exactly do you mean by 'backwards compatibility'? The driver API is different, of course. My conversion helpers can provide a starting point to move fbdev code into DRM drivers. For fbdev 2d-bitblt ioctls, you can add them to DRM drivers and set up DRM's fbdev emulation accordingly. Some DRM drivers do/did this. To my knowledge, so far there's not been a use case where that provides a benefit over simple memcpy. For fast 2d blitting from userspace, you should read Daniel's comment at [1]. tl;dr: a generic solution is non-trivial. Best regards Thomas [1] https://blog.ffwll.ch/2018/08/no-2d-in-drm.html > > Helge > > >>>> This not only to support "old" hardware, but also modern small OLED >>>> and e-ink displays. >>> >>> There's a DRM driver for Repaper e-Ink displays. So it seems doable at >>> least. >> >> Which uses an DRM_FORMAT_XRGB8888 intermediate, and >> drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed() >> to convert from truecolor to monochrome. I guess that would work, >> as this is a slow e-ink display. Have fun as a text console ;-) >> >> Gr{oetje,eeting}s, >> >> Geert >> >> -- >> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org >> >> In personal conversations with technical people, I call myself a hacker. But >> when I'm talking to journalists I just say "programmer" or something like that. >> -- Linus Torvalds >> >
On 1/17/22 16:00, Daniel Vetter wrote: > On Mon, Jan 17, 2022 at 1:16 PM Helge Deller <deller@gmx.de> wrote: >> >> Hello Daniel, >> >> On 1/17/22 11:02, Daniel Vetter wrote: >>> Hi Helge >>> >>> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote: >>>> >>>> The fbdev layer is orphaned, but seems to need some care. >>>> So I'd like to step up as new maintainer. >>>> >>>> Signed-off-by: Helge Deller <deller@gmx.de> >>>> >>>> diff --git a/MAINTAINERS b/MAINTAINERS >>>> index 5d0cd537803a..ce47dbc467cc 100644 >>>> --- a/MAINTAINERS >>>> +++ b/MAINTAINERS >>>> @@ -7583,11 +7583,12 @@ W: http://floatingpoint.sourceforge.net/emulator/index.html >>>> F: arch/x86/math-emu/ >>>> >>>> FRAMEBUFFER LAYER >>>> -L: dri-devel@lists.freedesktop.org >>>> +M: Helge Deller <deller@gmx.de> >>>> L: linux-fbdev@vger.kernel.org >>>> -S: Orphan >>> >>> Maybe don't rush maintainer changes in over the w/e without even bothering >>> to get any input from the people who've been maintaining it before. >>> >>> Because the status isn't entirely correct, fbdev core code and fbcon and >>> all that has been maintained, but in bugfixes only mode. And there's very >>> solid&important reasons to keep merging these patches through a drm tree, >>> because that's where all the driver development happens, and hence also >>> all the testing (e.g. the drm test suite has some fbdev tests - the only >>> automated ones that exist to my knowledge - and we run them in CI). So >>> moving that into an obscure new tree which isn't even in linux-next yet is >>> no good at all. >>> >>> Now fbdev driver bugfixes is indeed practically orphaned and I very much >>> welcome anyone stepping up for that, but the simplest approach there would >>> be to just get drm-misc commit rights and push the oddball bugfix in there >>> directly. But also if you want to do your own pull requests to Linus for >>> that I don't care and there's really no interference I think, so >>> whatever floats. >>> >>> But any code that is relevant for drm drivers really needs to go in through >>> drm trees, nothing else makes much sense. >>> >>> I guess you're first action as newly minted fbdev maintainer is going to be to >>> clean up the confusion you just created. >> >> Most of my machines depend on a working fbdev layer since drm isn't (and probably >> -due to technical requirements of DRM- won't be) available for those. >> So, since the fbdev drivers were marked orphaned, I decided to step up as maintainer. >> >> I see your point that at least the fbdev core code and fbcon are shared between DRM and fbdev. >> For me it's really not important to drive any patches through a seperate tree, so >> I'd be happy to join the drm-misc tree if you feel it's necessary. (By the way, >> adding my tree to for-next was on my todo list...) >> >> What's important for me though is, to keep fbdev actively maintained, which means: >> a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct, > > Yeah it'd be great if we have that, for a while Bart took care of > these, but had to step down again. drm-misc is maintained with the dim > scrip suite, which comes with docs and bash completion and everything. > Good starting pointer is here: > > https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html > > Process for getting commit rights is documented here: > > https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc > > But there's a pile more. I think once we've set that up and got it > going we can look at the bigger items. Some of them are fairly > low-hanging fruit, but the past 5+ years absolutely no one bothered to > step up and sort them out. Other problem areas in fbdev are extremely > hard to fix properly, without only doing minimal security-fixes only > support, so fair warning there. I think a good starting point would be > to read the patches and discussions for some of the things you've > reverted in your tree. > > Anyway I hope this gets you started, and hopefully after a minor > detour: Welcome to dri-devel, we're happy to take any help we can get, > there's lots to do! > Hello Daniel, you somehow missed to answer my main topics below...: > >> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be). >> I know of at least one driver which won't be able to support DRM.... >> Of course, if the hardware is capable to support DRM, it should be written for DRM and not applied for fbdev. >> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines, >> either when run on native hardware or in an emulator. >> d) not break DRM development >> >> Especially regarding c) I complained in [1] and got no feedback. I really would like to >> understand where the actual problems were and what's necessary to fix them. >> >> Helge >> >> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de > > >
On Mon, Jan 17, 2022 at 4:43 PM Helge Deller <deller@gmx.de> wrote: > > On 1/17/22 16:00, Daniel Vetter wrote: > > On Mon, Jan 17, 2022 at 1:16 PM Helge Deller <deller@gmx.de> wrote: > >> > >> Hello Daniel, > >> > >> On 1/17/22 11:02, Daniel Vetter wrote: > >>> Hi Helge > >>> > >>> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote: > >>>> > >>>> The fbdev layer is orphaned, but seems to need some care. > >>>> So I'd like to step up as new maintainer. > >>>> > >>>> Signed-off-by: Helge Deller <deller@gmx.de> > >>>> > >>>> diff --git a/MAINTAINERS b/MAINTAINERS > >>>> index 5d0cd537803a..ce47dbc467cc 100644 > >>>> --- a/MAINTAINERS > >>>> +++ b/MAINTAINERS > >>>> @@ -7583,11 +7583,12 @@ W: http://floatingpoint.sourceforge.net/emulator/index.html > >>>> F: arch/x86/math-emu/ > >>>> > >>>> FRAMEBUFFER LAYER > >>>> -L: dri-devel@lists.freedesktop.org > >>>> +M: Helge Deller <deller@gmx.de> > >>>> L: linux-fbdev@vger.kernel.org > >>>> -S: Orphan > >>> > >>> Maybe don't rush maintainer changes in over the w/e without even bothering > >>> to get any input from the people who've been maintaining it before. > >>> > >>> Because the status isn't entirely correct, fbdev core code and fbcon and > >>> all that has been maintained, but in bugfixes only mode. And there's very > >>> solid&important reasons to keep merging these patches through a drm tree, > >>> because that's where all the driver development happens, and hence also > >>> all the testing (e.g. the drm test suite has some fbdev tests - the only > >>> automated ones that exist to my knowledge - and we run them in CI). So > >>> moving that into an obscure new tree which isn't even in linux-next yet is > >>> no good at all. > >>> > >>> Now fbdev driver bugfixes is indeed practically orphaned and I very much > >>> welcome anyone stepping up for that, but the simplest approach there would > >>> be to just get drm-misc commit rights and push the oddball bugfix in there > >>> directly. But also if you want to do your own pull requests to Linus for > >>> that I don't care and there's really no interference I think, so > >>> whatever floats. > >>> > >>> But any code that is relevant for drm drivers really needs to go in through > >>> drm trees, nothing else makes much sense. > >>> > >>> I guess you're first action as newly minted fbdev maintainer is going to be to > >>> clean up the confusion you just created. > >> > >> Most of my machines depend on a working fbdev layer since drm isn't (and probably > >> -due to technical requirements of DRM- won't be) available for those. > >> So, since the fbdev drivers were marked orphaned, I decided to step up as maintainer. > >> > >> I see your point that at least the fbdev core code and fbcon are shared between DRM and fbdev. > >> For me it's really not important to drive any patches through a seperate tree, so > >> I'd be happy to join the drm-misc tree if you feel it's necessary. (By the way, > >> adding my tree to for-next was on my todo list...) > >> > >> What's important for me though is, to keep fbdev actively maintained, which means: > >> a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct, > > > > Yeah it'd be great if we have that, for a while Bart took care of > > these, but had to step down again. drm-misc is maintained with the dim > > scrip suite, which comes with docs and bash completion and everything. > > Good starting pointer is here: > > > > https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html > > > > Process for getting commit rights is documented here: > > > > https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc > > > > But there's a pile more. I think once we've set that up and got it > > going we can look at the bigger items. Some of them are fairly > > low-hanging fruit, but the past 5+ years absolutely no one bothered to > > step up and sort them out. Other problem areas in fbdev are extremely > > hard to fix properly, without only doing minimal security-fixes only > > support, so fair warning there. I think a good starting point would be > > to read the patches and discussions for some of the things you've > > reverted in your tree. > > > > Anyway I hope this gets you started, and hopefully after a minor > > detour: Welcome to dri-devel, we're happy to take any help we can get, > > there's lots to do! > > > > Hello Daniel, > > you somehow missed to answer my main topics below...: Well others replied on some specifics already, but for your reverts really read the commit message first. fbcon is full or broken locking and crashes that syzbot hits, so if you want to resurrect that code, those bugs need to be fixed first. Or at least some way to make sure that only people who don't care about serious issues in their kernel can use the code. We haven't done much maintainering, but we've tried to at least somewhat stay on top of the oopses and issues syzbot discovers (not even all of them unfortunately). Wrt useable console: shadow buffer + memcpy tends to be most performant, actually useful 2d acceleration is really hard. See the blog post Thomas linked. If you go with that, drm has you fully covered. None of the things you bring up are anything new really, and have been discussed at length over the past 5-10 years here on dri-devel. That's why I suggested that a good start is to focus on the simple fixes first, and meanwhile ramp up on the complexity you're volunteering for. There's some really tricky things going on here. -Daniel > > > >> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be). > >> I know of at least one driver which won't be able to support DRM.... > >> Of course, if the hardware is capable to support DRM, it should be written for DRM and not applied for fbdev. > >> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines, > >> either when run on native hardware or in an emulator. > >> d) not break DRM development > >> > >> Especially regarding c) I complained in [1] and got no feedback. I really would like to > >> understand where the actual problems were and what's necessary to fix them. > >> > >> Helge > >> > >> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de > > > > > > >
Hi Am 17.01.22 um 16:42 schrieb Helge Deller: > [...] >>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines, >>> either when run on native hardware or in an emulator. >>> d) not break DRM development >>> >>> Especially regarding c) I complained in [1] and got no feedback. I really would like to >>> understand where the actual problems were and what's necessary to fix them. >>> >>> Helge >>> >>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de Seems like few people read linux-fbdev these days. I suggest to partly revert the patch to the point were performance gets better again. Best regards Thomas >> >> >> >
Hi Thomas, On 1/17/22 16:05, Thomas Zimmermann wrote: > Hi > > Am 17.01.22 um 15:47 schrieb Helge Deller: >> On 1/17/22 15:10, Geert Uytterhoeven wrote: >> [...] >>> Using an XRGB32 intermediate would kill the user experience on old >>> machines, due to both increased memory usage and copy overhead. >>> >>>> Personally, I'd much appreciate if userspace would support more of the >>>> native formats and not rely on XRGB32. >>> >>> Supporting monochrome, 16 colors, and 256 colors would be nice. >> >> From this conversation it seems DRM completely lacks backwards compatibility, >> including a missing 2D bitblt copy. >> Isn't that all what's needed and then migrating existing drivers would >> be easy ? > > What exactly do you mean by 'backwards compatibility'? DRM to provide possibility to run (in at least a few) of the bitmap formats mentioned above. > The driver API is different, of course. Sure. I would think of a defined set how to activate a special graphics output. And a function to do on-screen 2D bitblt to move contents (for usage of fbcon emulation). > My conversion helpers can provide a starting point to move fbdev code > into DRM drivers. I need to look into this. > For fbdev 2d-bitblt ioctls, I'm not talking about 2d bitblt "IOCTLS". I'm talking about fbcon utilizing 2D graphic card bitblt to move on-screen contents to speed up a text console. E.g. text upwards scrolling. > you can add them to DRM drivers and set > up DRM's fbdev emulation accordingly. Some DRM drivers do/did this. > To my knowledge, so far there's not been a use case where that > provides a benefit over simple memcpy. It's a huge difference on older machines with slower busses for example. So, for text console emulation, moving windows ... it's important. > For fast 2d blitting from userspace, you should read Daniel's comment > at [1]. tl;dr: a generic solution is non-trivial. Probably. I think fbdev doesn't provide that functionality either today (at least I think so) - so that's probably not a focus (and not relevant regading the "backwards compatibility" I mentioned). Helge > Best regards > Thomas > > [1] https://blog.ffwll.ch/2018/08/no-2d-in-drm.html > >> >> Helge >> >> >>>>> This not only to support "old" hardware, but also modern small OLED >>>>> and e-ink displays. >>>> >>>> There's a DRM driver for Repaper e-Ink displays. So it seems doable at >>>> least. >>> >>> Which uses an DRM_FORMAT_XRGB8888 intermediate, and >>> drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed() >>> to convert from truecolor to monochrome. I guess that would work, >>> as this is a slow e-ink display. Have fun as a text console ;-) >>> >>> Gr{oetje,eeting}s, >>> >>> Geert >>> >>> -- >>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org >>> >>> In personal conversations with technical people, I call myself a hacker. But >>> when I'm talking to journalists I just say "programmer" or something like that. >>> -- Linus Torvalds >>> >> >
On 1/17/22 16:58, Thomas Zimmermann wrote: > Hi > > Am 17.01.22 um 16:42 schrieb Helge Deller: >> [...] >>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines, >>>> either when run on native hardware or in an emulator. >>>> d) not break DRM development >>>> >>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to >>>> understand where the actual problems were and what's necessary to fix them. >>>> >>>> Helge >>>> >>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de > > Seems like few people read linux-fbdev these days. > I suggest to partly revert the patch to the point were performance > gets better again. Yes, *please*! That would solve my biggest concern. As far as I can see that's only 2 commits to be reverted: b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)" 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next I think both were not related to any 0-day bug reports (but again, I might be wrong). Helge
On Mon, Jan 17, 2022 at 5:22 PM Helge Deller <deller@gmx.de> wrote: > > On 1/17/22 16:58, Thomas Zimmermann wrote: > > Hi > > > > Am 17.01.22 um 16:42 schrieb Helge Deller: > >> [...] > >>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines, > >>>> either when run on native hardware or in an emulator. > >>>> d) not break DRM development > >>>> > >>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to > >>>> understand where the actual problems were and what's necessary to fix them. > >>>> > >>>> Helge > >>>> > >>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de > > > > Seems like few people read linux-fbdev these days. > > I suggest to partly revert the patch to the point were performance > > gets better again. > Yes, *please*! > That would solve my biggest concern. > > As far as I can see that's only 2 commits to be reverted: > b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)" > 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next > > I think both were not related to any 0-day bug reports (but again, I might be wrong). syzbot, not 0day, and there's like a sea of them unfortunately. There's all kinds of funny races going on when resizing consoles (due to bad locking design) which then blow up, especially in less tested code. For the sw rendering we've merged a bunch of patches, but you pretty much have to assume that it's all fairly broken code until it's rewritten and fully covered with tests. Shadowfb + memcpy is probably much faster for restoring scrolling performance than anything else really. -Daniel
On 1/17/22 17:38, Daniel Vetter wrote: > On Mon, Jan 17, 2022 at 5:22 PM Helge Deller <deller@gmx.de> wrote: >> >> On 1/17/22 16:58, Thomas Zimmermann wrote: >>> Hi >>> >>> Am 17.01.22 um 16:42 schrieb Helge Deller: >>>> [...] >>>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines, >>>>>> either when run on native hardware or in an emulator. >>>>>> d) not break DRM development >>>>>> >>>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to >>>>>> understand where the actual problems were and what's necessary to fix them. >>>>>> >>>>>> Helge >>>>>> >>>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de >>> >>> Seems like few people read linux-fbdev these days. >>> I suggest to partly revert the patch to the point were performance >>> gets better again. >> Yes, *please*! >> That would solve my biggest concern. >> >> As far as I can see that's only 2 commits to be reverted: >> b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)" >> 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next >> >> I think both were not related to any 0-day bug reports (but again, I might be wrong). > > syzbot, not 0day, and there's like a sea of them unfortunately. > There's all kinds of funny races going on when resizing consoles (due The patches above are not about resizing consoles. Even if a resize should happen in between, it's better to introduce some kind of big lock instead of completely disable acceleration for est. 58 other graphic card drivers and slow them down that much that it renders them to become unusable. > to bad locking design) which then blow up, especially in less tested > code. For the sw rendering we've merged a bunch of patches, but you > pretty much have to assume that it's all fairly broken code until it's > rewritten and fully covered with tests. Shadowfb + memcpy is probably > much faster for restoring scrolling performance than anything else > really. That's maybe true for fast new machines with fast PCI busses. But have you measured that on other/older hardware too? There is a good reason why 2D acceleration was introduced. Helge
Hi Thomas, Thomas Zimmermann <tzimmermann@suse.de> writes: > Hi > > Am 14.01.22 um 19:11 schrieb Helge Deller: >> The fbdev layer is orphaned, but seems to need some care. >> So I'd like to step up as new maintainer. >> Signed-off-by: Helge Deller <deller@gmx.de> > > First of all, thank you for stepping up to maintain the fbdev > codebase. It really needs someone actively looking after it. > > And now comes the BUT. > > I want to second everything said by Danial and Javier. In addition to > purely organizational topics (trees, PRs, etc), there are a number of > inherit problems with fbdev. > > * It's 90s technology. Neither does it fit today's userspace, not > hardware. If you have more than just the most trivial of graphical > output fbdev isn't for you. > > * There's no new development in fbdev and there are no new > drivers. Everyone works on DRM, which is better in most > regards. The consequence is that userspace is slowly loosing the > ability to use fbdev. That might be caused by the fact that no new drivers are accepted for fbdev. I wrote a driver for the HP Visualize FX5/10 cards end of last year which was rejected for inclusion into fbdev[1]. Based on your recommendation i re-wrote the whole thing in DRM. This works but has several drawbacks: - no modesetting. With fbdev, i can nicely switch resolutions with fbset. That doesn't work, and i've been told that this is not supported[2] - It is *much* slower than fbset with hardware blitting. I would have to dig out the numbers, but it's in the ratio of 1:15. The nice thing with fbdev blitting is that i get an array of pixels and the foreground/background colors all of these these pixels should have. With the help of the hardware blitting, i can write 32 pixels at once with every 32-bit transfer. With DRM, the closest i could find was DRM_FORMAT_C8, which means one byte per pixel. So i can put 4 pixels into one 32-bit transfer. fbdev also clears the lines with hardware blitting, which is much faster than clearing it with memcpy. Based on your recommendation i also verified that pci coalescing is enabled. These numbers are with DRM's unnatural scrolling behaviour - it seems to scroll several (text)lines at once if it takes to much time. I guess if DRM would scroll line by line it would be even slower. If DRM would add those things - hardware clearing of memory regions, hw blitting for text with a FG/BG color and modesetting i wouldn't care about fbdev at all. But right now, it's working way faster for me. I also tested the speed on my Thinkpad X1 with Intel graphics, and there a dmesg with 919 lines one the text console took about 2s to display. In x11, i measure 22ms. This might be unfair because encoding might be different, but i cannot confirm the 'memcpy' is faster than hardware blitting' point. I think if that would be the case, no-one would care about 2D acceleration. Don't get me wrong, i'm not saying there's no reason for DRM. I fully understand why it exists and think it's a good way to go. But for system where a (fast) local console is required without X11, fbdev might be the better choice at the moment. Regards Sven [1] https://lore.kernel.org/all/87ee7qvcc7.fsf@x1.stackframe.org/T/#m57cdea83608fc78bfc6c2e76eb037bf82017b302 [2] https://lore.kernel.org/all/87ee7qvcc7.fsf@x1.stackframe.org/T/#m46a52815036a958f6a11d2f3f62e1340a09bd981
On 1/17/22 17:21, Helge Deller wrote: > On 1/17/22 16:58, Thomas Zimmermann wrote: >> Hi >> >> Am 17.01.22 um 16:42 schrieb Helge Deller: >>> [...] >>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines, >>>>> either when run on native hardware or in an emulator. >>>>> d) not break DRM development >>>>> >>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to >>>>> understand where the actual problems were and what's necessary to fix them. >>>>> >>>>> Helge >>>>> >>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de >> >> Seems like few people read linux-fbdev these days. >> I suggest to partly revert the patch to the point were performance >> gets better again. > Yes, *please*! > That would solve my biggest concern. > > As far as I can see that's only 2 commits to be reverted: > b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)" > 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next > > I think both were not related to any 0-day bug reports (but again, I might be wrong). I did some more checking... Both patches are not related to DRM, since no DRM driver sets the FBINFO_HWACCEL_COPYAREA or FBINFO_HWACCEL_FILLRECT flags. Reverting those would bring back fbdev performance which I'm worried most about. And it introduces no (positive or negative) effects on DRM. I still wonder why those were submitted. Let's please revert those. Helge
On 1/17/22 16:03, Daniel Vetter wrote: > On Mon, Jan 17, 2022 at 3:48 PM Helge Deller <deller@gmx.de> wrote: >> >> On 1/17/22 15:10, Geert Uytterhoeven wrote: >>> Hi Thomas, >>> >>> On Mon, Jan 17, 2022 at 2:51 PM Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>> Am 17.01.22 um 14:29 schrieb Geert Uytterhoeven: >>>>> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote: >>>>>>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be). >>>>>>> I know of at least one driver which won't be able to support DRM.... >>>>>> >>>>>> Hmm? I seriously doubt that. There is always the option to use a >>>>>> shadow framebuffer, then convert from standard drm formats to whatever >>>>>> esoteric pixel format your hardware expects. >>>>>> >>>>>> Been there, done that. Have a look at the cirrus driver. The physical >>>>>> hardware was designed in the early 90-ies, almost 30 years ago. These >>>>>> days it exists in virtual form only (qemu emulates it). Thanks to the >>>>>> drm driver it runs wayland just fine even though it has a bunch of >>>>>> constrains dictated by the hardware design. >>>>> >>>>> The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888) >>>>> modes only. The Cirrus fbdev driver also supports mochrome and 256 >>>>> color modes. >>>>> >>>>> There exist some DRM drivers that do support DRM_FORMAT_C8, but none of >>>>> the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}. Using a shadow >>>>> frame buffer to convert from truecolor to 256 colors would be doable, >>>>> but would give bad results. And what about less colors? >>>>> Adding support for e.g. DRM_FORMAT_C4 is not straight-forward, as >>>>> the DRM core assumes in many places that a pixel is at least 1 byte, >>>>> and would crash otherwise (yes I tried). Other modes needed are >>>>> DRM_FORMAT_Y4 and DRM_FORMAT_{BW,WB} (monochrome). >>>> >>>> We export XRGB32 from each driver, because userspace expects it. But >>>> that is not a hard requirement. Userspace can use any format. It's just >>>> that no one seems to have any use cases so far, so no work has been >>>> done. Think of XRGB32 as a fallback. >>> >>> Using an XRGB32 intermediate would kill the user experience on old >>> machines, due to both increased memory usage and copy overhead. >>> >>>> Personally, I'd much appreciate if userspace would support more of the >>>> native formats and not rely on XRGB32. >>> >>> Supporting monochrome, 16 colors, and 256 colors would be nice. >> >> From this conversation it seems DRM completely lacks backwards compatibility, >> including a missing 2D bitblt copy. >> Isn't that all what's needed and then migrating existing drivers would >> be easy ? > > Not sure who you talked to, but we have drivers with fbdev bitblt > accel (well, in some cases had, because driver maintainers decided > it's just not worth it and ripped it out again or never merged it). > Also the other discussions about some low-bit formats is pretty much > just a question of extending a few enums and wiring through the fbdev > emulation layer. No, you got me wrong. I'm not talking about making other low-bit formats available to userspace. I'm talking about running the framebuffer natively on a lower-bit format and to speed up text emulation (fbcon) with help of on-chip 2D bitblt. So, similiar as it was done in fbdev for non-DRM graphic cards before two patches were applied and which disabled this speedup for *all* existing fbdev drivers: b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)" 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next Esp. the commit message of patch 39aead8373b3 completely ignored the acceleration of the fbdev drivers. Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is currently unaccelerated and bound to Truecolour modes only, which is probably one of the main reasons why most fbdev drivers can't be ported to DRM... Helge > So the things brought up in this thread thus far are > actually the fairly easy items, which should take at most a handful of > patches to rectify. There's much more nastier issues in fbdev, which > will take serious amounts of development time to fix. > > Unfortunately in the past 5+ years absolutely no one stepped up with > actual patches, which is why fbdev was marked as orphaned in > MAINTAINERS. > -Daniel > >> >> Helge >> >> >>>>> This not only to support "old" hardware, but also modern small OLED >>>>> and e-ink displays. >>>> >>>> There's a DRM driver for Repaper e-Ink displays. So it seems doable at >>>> least. >>> >>> Which uses an DRM_FORMAT_XRGB8888 intermediate, and >>> drm_fb_xrgb8888_to_gray8() and repaper_gray8_to_mono_reversed() >>> to convert from truecolor to monochrome. I guess that would work, >>> as this is a slow e-ink display. Have fun as a text console ;-) >>> >>> Gr{oetje,eeting}s, >>> >>> Geert >>> >>> -- >>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org >>> >>> In personal conversations with technical people, I call myself a hacker. But >>> when I'm talking to journalists I just say "programmer" or something like that. >>> -- Linus Torvalds >>> >> > >
On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Seems like few people read linux-fbdev these days.
How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
also? Do we still need a separate linux-fbdev mailing list at all?
BR,
Jani.
On 1/17/22 22:40, Jani Nikula wrote: > On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote: >> Seems like few people read linux-fbdev these days. > > How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel > also? Doesn't seem like much traffic - which IMHO is OK for such a tree with mostly just maintenance patches. > Do we still need a separate linux-fbdev mailing list at all? Yes. I want to have it seperate of dri-devel. Actually I'd prefer to drop dri-devel from the list where patches for fbdev are sent... Helge
On Mon, Jan 17, 2022 at 2:47 PM Helge Deller <deller@gmx.de> wrote: > > On 1/17/22 17:21, Helge Deller wrote: > > On 1/17/22 16:58, Thomas Zimmermann wrote: > >> Hi > >> > >> Am 17.01.22 um 16:42 schrieb Helge Deller: > >>> [...] > >>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines, > >>>>> either when run on native hardware or in an emulator. > >>>>> d) not break DRM development > >>>>> > >>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to > >>>>> understand where the actual problems were and what's necessary to fix them. > >>>>> > >>>>> Helge > >>>>> > >>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de > >> > >> Seems like few people read linux-fbdev these days. > >> I suggest to partly revert the patch to the point were performance > >> gets better again. > > Yes, *please*! > > That would solve my biggest concern. > > > > As far as I can see that's only 2 commits to be reverted: > > b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)" > > 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next > > > > I think both were not related to any 0-day bug reports (but again, I might be wrong). > > I did some more checking... > > Both patches are not related to DRM, since no DRM driver sets the > FBINFO_HWACCEL_COPYAREA or FBINFO_HWACCEL_FILLRECT flags. These used to be set by, at least, nouveau (which is a drm driver). And yeah, console responsiveness is _way_ worse without that. People keep pushing the messaging that it's the same speed to do it as memcpy, but that's just not the case in my experience, on a pretty bog-standard x86 desktop. The support got dumped, and it felt pretty clear from the messaging at the time, "too bad". Would love to see it come back. Cheers, -ilia
On Mon, Jan 17, 2022 at 02:29:47PM +0100, Geert Uytterhoeven wrote: > Hi Gerd, > > On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote: > > > b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be). > > > I know of at least one driver which won't be able to support DRM.... > > > > Hmm? I seriously doubt that. There is always the option to use a > > shadow framebuffer, then convert from standard drm formats to whatever > > esoteric pixel format your hardware expects. > > > > Been there, done that. Have a look at the cirrus driver. The physical > > hardware was designed in the early 90-ies, almost 30 years ago. These > > days it exists in virtual form only (qemu emulates it). Thanks to the > > drm driver it runs wayland just fine even though it has a bunch of > > constrains dictated by the hardware design. > > The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888) > modes only. The Cirrus fbdev driver also supports mochrome and 256 > color modes. > > There exist some DRM drivers that do support DRM_FORMAT_C8, but none of > the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}. Adding that to the cirrus driver shouldn't be hard. I'm wondering whenever there are any userspace apps which would actually use that though. take care, Gerd
Hi, > Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is > currently unaccelerated and bound to Truecolour modes only, Yes. Adding support for formats beside argb8888 to the drm fbcon emulation shouldn't be that much of a problem though. Acceleration is harder. The scroll acceleration had issues nobody addressed for years, and on modern hardware it is simply not used, which is probably the reason nobody stepped up fixing things and it ended up being dropped. Bringing it back is much more work than just reverting the commits removing it. Also note that using a shadow framebuffer allows to decouple fbcon updates and scanout framebuffer updates. Can be used to speed up things without depending on the 2d blitter. take care, Gerd
On 1/18/22 07:11, Gerd Hoffmann wrote: > On Mon, Jan 17, 2022 at 02:29:47PM +0100, Geert Uytterhoeven wrote: >> Hi Gerd, >> >> On Mon, Jan 17, 2022 at 1:57 PM Gerd Hoffmann <kraxel@redhat.com> wrote: >>>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be). >>>> I know of at least one driver which won't be able to support DRM.... >>> >>> Hmm? I seriously doubt that. There is always the option to use a >>> shadow framebuffer, then convert from standard drm formats to whatever >>> esoteric pixel format your hardware expects. >>> >>> Been there, done that. Have a look at the cirrus driver. The physical >>> hardware was designed in the early 90-ies, almost 30 years ago. These >>> days it exists in virtual form only (qemu emulates it). Thanks to the >>> drm driver it runs wayland just fine even though it has a bunch of >>> constrains dictated by the hardware design. >> >> The Cirrus DRM driver supports TrueColor (RGB565/888 and ARGB8888) >> modes only. The Cirrus fbdev driver also supports mochrome and 256 >> color modes. >> >> There exist some DRM drivers that do support DRM_FORMAT_C8, but none of >> the "tiny" ones do. Same for DRM_FORMAT_RGB{332,233}. > > Adding that to the cirrus driver shouldn't be hard. I'm wondering > whenever there are any userspace apps which would actually use that > though. The discussion is not about userspace apps. It's about the case, that if existing fbdev drivers should be converted to DRM, then they are currently required to run in TrueColor. Some of those cards/drivers don't support TrueColor (which is problem #1), and even if they do, then only with their existing 2D bitblt acceleration they are somewhat performance-wise useable as framebuffer console (problem #2). So, if DRM would natively support other formats, then it's not hard to convert them to DRM. Helge
Hi Gerd, On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann <kraxel@redhat.com> wrote: > Also note that using a shadow framebuffer allows to decouple fbcon > updates and scanout framebuffer updates. Can be used to speed up > things without depending on the 2d blitter. Assuming accesses to the shadow frame buffer are faster than accesses to the scanout frame buffer. While this is true on modern hardware, this is not the case on all hardware. Especially if the shadow frame buffer has a higher depth (XRGB8888) than the scanout frame buffer (e.g. Cn)... The funny thing is that the systems we are interested in, once used to be known for their graphics capabilities and/or performance... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On 1/18/22 07:29, Gerd Hoffmann wrote: >> Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is >> currently unaccelerated and bound to Truecolour modes only, > > Yes. Adding support for formats beside argb8888 to the drm fbcon > emulation shouldn't be that much of a problem though. Really? Assuming a graphic card which runs with only 256 colors framebuffer is easily supported by DRM, and you can use fbcon without using lots of memcpy()? > Acceleration is harder. The scroll acceleration had issues nobody > addressed for years, and on modern hardware it is simply not used, which > is probably the reason nobody stepped up fixing things and it ended up > being dropped. The DRM layer doesn't use scroll acceleration. More than 30 other existing fbdev drivers use it. > Bringing it back is much more work than just reverting the commits removing it. Reverting those commits have no effect on DRM's usage of fbcon. But reverting those commits bring back scroll acceleration for all others. I'm trying to find out which patches did apparently fixed such issues for the REDRAW case. If you have a pointer it would be helpful. > Also note that using a shadow framebuffer allows to decouple fbcon > updates and scanout framebuffer updates. Can be used to speed up > things without depending on the 2d blitter. Not on older hardware. Helge
On Mon, 17 Jan 2022 19:47:39 +0100 Sven Schnelle <svens@stackframe.org> wrote: > I also tested the speed on my Thinkpad X1 with Intel graphics, and there > a dmesg with 919 lines one the text console took about 2s to display. In > x11, i measure 22ms. This might be unfair because encoding might be > different, but i cannot confirm the 'memcpy' is faster than hardware > blitting' point. I think if that would be the case, no-one would care > about 2D acceleration. I think that is an extremely unfair comparison, because a graphical terminal app is not going to render every line of text streamed to it. It probably renders only the final view alone if you simply run 'dmesg', skipping the first 800-900 lines completely. Maybe fbcon should do the same when presented with a flood of text, but I don't know how or why it works like it works. I assume in your two second test you actually see some scrolling (animation) rather than the final view? Or does it take 2 seconds just to update one screenful? I doubt your fbcon and terminal window had height of 919 lines? Thanks, pq
On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote: > On 1/17/22 22:40, Jani Nikula wrote: >> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>> Seems like few people read linux-fbdev these days. >> >> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel >> also? > > Doesn't seem like much traffic - which IMHO is OK for such a tree with > mostly just maintenance patches. > >> Do we still need a separate linux-fbdev mailing list at all? > > Yes. I want to have it seperate of dri-devel. > Actually I'd prefer to drop dri-devel from the list where patches > for fbdev are sent... Disagreed. If anything, this thread shows we can't have fbdev and drm in silos of their own. Also, if the patches continue to get merged through drm-misc, they need to be sent to dri-devel. BR, Jani.
Hi Jani, On Tue, Jan 18, 2022 at 9:38 AM Jani Nikula <jani.nikula@linux.intel.com> wrote: > On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote: > > On 1/17/22 22:40, Jani Nikula wrote: > >> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote: > >>> Seems like few people read linux-fbdev these days. > >> > >> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel > >> also? > > > > Doesn't seem like much traffic - which IMHO is OK for such a tree with > > mostly just maintenance patches. > > > >> Do we still need a separate linux-fbdev mailing list at all? > > > > Yes. I want to have it seperate of dri-devel. > > Actually I'd prefer to drop dri-devel from the list where patches > > for fbdev are sent... > > Disagreed. If anything, this thread shows we can't have fbdev and drm in > silos of their own. Unless DRM drops fbdev support. Isn't that the long-term plan anyway? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hello Daniel, On 1/17/22 16:00, Daniel Vetter wrote: > On Mon, Jan 17, 2022 at 1:16 PM Helge Deller <deller@gmx.de> wrote: >> On 1/17/22 11:02, Daniel Vetter wrote: >>> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote: >>>> >>>> The fbdev layer is orphaned, but seems to need some care. >>>> So I'd like to step up as new maintainer. >>>> >>>> Signed-off-by: Helge Deller <deller@gmx.de> >>>> >>>> diff --git a/MAINTAINERS b/MAINTAINERS >>>> index 5d0cd537803a..ce47dbc467cc 100644 >>>> --- a/MAINTAINERS >>>> +++ b/MAINTAINERS >>>> @@ -7583,11 +7583,12 @@ W: http://floatingpoint.sourceforge.net/emulator/index.html >>>> F: arch/x86/math-emu/ >>>> >>>> FRAMEBUFFER LAYER >>>> -L: dri-devel@lists.freedesktop.org >>>> +M: Helge Deller <deller@gmx.de> >>>> L: linux-fbdev@vger.kernel.org >>>> -S: Orphan >>> >>> Maybe don't rush maintainer changes in over the w/e without even bothering >>> to get any input from the people who've been maintaining it before. >>> >>> Because the status isn't entirely correct, fbdev core code and fbcon and >>> all that has been maintained, but in bugfixes only mode. And there's very >>> solid&important reasons to keep merging these patches through a drm tree, >>> because that's where all the driver development happens, and hence also >>> all the testing (e.g. the drm test suite has some fbdev tests - the only >>> automated ones that exist to my knowledge - and we run them in CI). So >>> moving that into an obscure new tree which isn't even in linux-next yet is >>> no good at all. >>> >>> Now fbdev driver bugfixes is indeed practically orphaned and I very much >>> welcome anyone stepping up for that, but the simplest approach there would >>> be to just get drm-misc commit rights and push the oddball bugfix in there >>> directly. But also if you want to do your own pull requests to Linus for >>> that I don't care and there's really no interference I think, so >>> whatever floats. >>> >>> But any code that is relevant for drm drivers really needs to go in through >>> drm trees, nothing else makes much sense. >>> >>> I guess you're first action as newly minted fbdev maintainer is going to be to >>> clean up the confusion you just created. >> >> Most of my machines depend on a working fbdev layer since drm isn't (and probably >> -due to technical requirements of DRM- won't be) available for those. >> So, since the fbdev drivers were marked orphaned, I decided to step up as maintainer. >> >> I see your point that at least the fbdev core code and fbcon are shared between DRM and fbdev. >> For me it's really not important to drive any patches through a seperate tree, so >> I'd be happy to join the drm-misc tree if you feel it's necessary. (By the way, >> adding my tree to for-next was on my todo list...) >> >> What's important for me though is, to keep fbdev actively maintained, which means: >> a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct, > > Yeah it'd be great if we have that, for a while Bart took care of > these, but had to step down again. drm-misc is maintained with the dim > scrip suite, which comes with docs and bash completion and everything. > Good starting pointer is here: > > https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html > > Process for getting commit rights is documented here: > > https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc > > But there's a pile more. I think once we've set that up and got it > going we can look at the bigger items. Some of them are fairly > low-hanging fruit, but the past 5+ years absolutely no one bothered to > step up and sort them out. Other problem areas in fbdev are extremely > hard to fix properly, without only doing minimal security-fixes only > support, so fair warning there. I think a good starting point would be > to read the patches and discussions for some of the things you've > reverted in your tree. > > Anyway I hope this gets you started, and hopefully after a minor > detour: Welcome to dri-devel, we're happy to take any help we can get, > there's lots to do! Thanks for this info, Daniel! After reading those docs I've decided not to join dri-devel and keep my existing linux-fbdev tree at: https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git The linux-fbdev is a low-volume mailing list with mostly small bug fixes or enhancements for the fbdev drivers. Those patches usually don't affect DRM. I'm expecting that non-trivial changes which may affect fbdev will be sent to the linux-fbdev mailing list, same way as I will of course send any patches which might affect DRM to dri-devel. My git tree is wired up to the for-next pull chain, so in any way we would notice merge conflicts (which I believe will not happen). Cheers, Helge >> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be). >> I know of at least one driver which won't be able to support DRM.... >> Of course, if the hardware is capable to support DRM, it should be written for DRM and not applied for fbdev. >> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines, >> either when run on native hardware or in an emulator. >> d) not break DRM development >> >> Especially regarding c) I complained in [1] and got no feedback. I really would like to >> understand where the actual problems were and what's necessary to fix them. >> >> Helge >> >> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de > > >
On 1/18/22 09:38, Jani Nikula wrote: > On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote: >> On 1/17/22 22:40, Jani Nikula wrote: >>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>> Seems like few people read linux-fbdev these days. >>> >>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel >>> also? >> >> Doesn't seem like much traffic - which IMHO is OK for such a tree with >> mostly just maintenance patches. >> >>> Do we still need a separate linux-fbdev mailing list at all? >> >> Yes. I want to have it seperate of dri-devel. >> Actually I'd prefer to drop dri-devel from the list where patches >> for fbdev are sent... > > Disagreed. If anything, this thread shows we can't have fbdev and drm in > silos of their own. Patches to fbdev usually don't affect DRM. Patches which affect DRM needs to through to dri-devel. In addition this would take the burden of the dri-developers to receive unrelated fbdev driver updates and patches. > Also, if the patches continue to get merged through drm-misc, they need > to be sent to dri-devel. Helge
On 2022-01-17 19:47, Sven Schnelle wrote: > >> * There's no new development in fbdev and there are no new >> drivers. Everyone works on DRM, which is better in most >> regards. The consequence is that userspace is slowly loosing the >> ability to use fbdev. > > That might be caused by the fact that no new drivers are accepted for > fbdev. I wrote a driver for the HP Visualize FX5/10 cards end of last > year which was rejected for inclusion into fbdev[1]. > > Based on your recommendation i re-wrote the whole thing in DRM. This > works but has several drawbacks: > > - no modesetting. With fbdev, i can nicely switch resolutions with > fbset. That doesn't work, and i've been told that this is not supported[2] > > - It is *much* slower than fbset with hardware blitting. I would have to > dig out the numbers, but it's in the ratio of 1:15. The nice thing > with fbdev blitting is that i get an array of pixels and the > foreground/background colors all of these these pixels should have. > With the help of the hardware blitting, i can write 32 pixels at once > with every 32-bit transfer. > > With DRM, the closest i could find was DRM_FORMAT_C8, which means one > byte per pixel. So i can put 4 pixels into one 32-bit transfer. > > fbdev also clears the lines with hardware blitting, which is much > faster than clearing it with memcpy. > > Based on your recommendation i also verified that pci coalescing is > enabled. > > These numbers are with DRM's unnatural scrolling behaviour - it seems > to scroll several (text)lines at once if it takes to much time. I > guess if DRM would scroll line by line it would be even slower. > > If DRM would add those things - hardware clearing of memory regions, > hw blitting for text with a FG/BG color and modesetting i wouldn't > care about fbdev at all. But right now, it's working way faster for me. A DRM driver can implement the same fbdev acceleration hooks as an fbdev driver. (Most DRM drivers never bothered because the HW is more complex than traditional 2D accelerators, and can't safely be used under all circumstances where fbdev acceleration hooks could get called from. That's not an issue for a traditional 2D accelerator driver though)
On 1/18/22 09:41, Helge Deller wrote: > Hello Daniel, > > On 1/17/22 16:00, Daniel Vetter wrote: >> On Mon, Jan 17, 2022 at 1:16 PM Helge Deller <deller@gmx.de> wrote: >>> On 1/17/22 11:02, Daniel Vetter wrote: >>>> On Fri, Jan 14, 2022 at 7:18 PM Helge Deller <deller@gmx.de> wrote: >>>>> >>>>> The fbdev layer is orphaned, but seems to need some care. >>>>> So I'd like to step up as new maintainer. >>>>> >>>>> Signed-off-by: Helge Deller <deller@gmx.de> >>>>> >>>>> diff --git a/MAINTAINERS b/MAINTAINERS >>>>> index 5d0cd537803a..ce47dbc467cc 100644 >>>>> --- a/MAINTAINERS >>>>> +++ b/MAINTAINERS >>>>> @@ -7583,11 +7583,12 @@ W: http://floatingpoint.sourceforge.net/emulator/index.html >>>>> F: arch/x86/math-emu/ >>>>> >>>>> FRAMEBUFFER LAYER >>>>> -L: dri-devel@lists.freedesktop.org >>>>> +M: Helge Deller <deller@gmx.de> >>>>> L: linux-fbdev@vger.kernel.org >>>>> -S: Orphan >>>> >>>> Maybe don't rush maintainer changes in over the w/e without even bothering >>>> to get any input from the people who've been maintaining it before. >>>> >>>> Because the status isn't entirely correct, fbdev core code and fbcon and >>>> all that has been maintained, but in bugfixes only mode. And there's very >>>> solid&important reasons to keep merging these patches through a drm tree, >>>> because that's where all the driver development happens, and hence also >>>> all the testing (e.g. the drm test suite has some fbdev tests - the only >>>> automated ones that exist to my knowledge - and we run them in CI). So >>>> moving that into an obscure new tree which isn't even in linux-next yet is >>>> no good at all. >>>> >>>> Now fbdev driver bugfixes is indeed practically orphaned and I very much >>>> welcome anyone stepping up for that, but the simplest approach there would >>>> be to just get drm-misc commit rights and push the oddball bugfix in there >>>> directly. But also if you want to do your own pull requests to Linus for >>>> that I don't care and there's really no interference I think, so >>>> whatever floats. >>>> >>>> But any code that is relevant for drm drivers really needs to go in through >>>> drm trees, nothing else makes much sense. >>>> >>>> I guess you're first action as newly minted fbdev maintainer is going to be to >>>> clean up the confusion you just created. >>> >>> Most of my machines depend on a working fbdev layer since drm isn't (and probably >>> -due to technical requirements of DRM- won't be) available for those. >>> So, since the fbdev drivers were marked orphaned, I decided to step up as maintainer. >>> >>> I see your point that at least the fbdev core code and fbcon are shared between DRM and fbdev. >>> For me it's really not important to drive any patches through a seperate tree, so >>> I'd be happy to join the drm-misc tree if you feel it's necessary. (By the way, >>> adding my tree to for-next was on my todo list...) >>> >>> What's important for me though is, to keep fbdev actively maintained, which means: >>> a) to get fixes which were posted to fbdev mailing list applied if they are useful & correct, >> >> Yeah it'd be great if we have that, for a while Bart took care of >> these, but had to step down again. drm-misc is maintained with the dim >> scrip suite, which comes with docs and bash completion and everything. >> Good starting pointer is here: >> >> https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html >> >> Process for getting commit rights is documented here: >> >> https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc >> >> But there's a pile more. I think once we've set that up and got it >> going we can look at the bigger items. Some of them are fairly >> low-hanging fruit, but the past 5+ years absolutely no one bothered to >> step up and sort them out. Other problem areas in fbdev are extremely >> hard to fix properly, without only doing minimal security-fixes only >> support, so fair warning there. I think a good starting point would be >> to read the patches and discussions for some of the things you've >> reverted in your tree. >> >> Anyway I hope this gets you started, and hopefully after a minor >> detour: Welcome to dri-devel, we're happy to take any help we can get, >> there's lots to do! > > Thanks for this info, Daniel! > > After reading those docs I've decided not to join dri-devel and keep > my existing linux-fbdev tree at: > > https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git > > The linux-fbdev is a low-volume mailing list with mostly small bug fixes > or enhancements for the fbdev drivers. Those patches usually don't affect DRM. > > I'm expecting that non-trivial changes which may affect fbdev will be sent to the > linux-fbdev mailing list, same way as I will of course send any patches which > might affect DRM to dri-devel. > > My git tree is wired up to the for-next pull chain, so in any way we would notice > merge conflicts (which I believe will not happen). To make it more clear: I'm not planning to push code to fbdev/fbcon without having discussed everything on dri-devel. Everything which somehow would affect DRM needs to be discussed on dri-devel and then - after agreement - either pushed via the fbdev git tree or the drm-misc tree. Helge > Cheers, > > Helge > >>> b) to include new drivers (for old hardware) if they arrive (probably happens rarely but there can be). >>> I know of at least one driver which won't be able to support DRM.... >>> Of course, if the hardware is capable to support DRM, it should be written for DRM and not applied for fbdev. >>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines, >>> either when run on native hardware or in an emulator. >>> d) not break DRM development >>> >>> Especially regarding c) I complained in [1] and got no feedback. I really would like to >>> understand where the actual problems were and what's necessary to fix them. >>> >>> Helge >>> >>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de >> >> >> >
On Tue, Jan 18, 2022 at 09:20:43AM +0100, Helge Deller wrote: > On 1/18/22 07:29, Gerd Hoffmann wrote: > >> Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is > >> currently unaccelerated and bound to Truecolour modes only, > > > > Yes. Adding support for formats beside argb8888 to the drm fbcon > > emulation shouldn't be that much of a problem though. > > Really? Assuming a graphic card which runs with only 256 colors framebuffer > is easily supported by DRM, and you can use fbcon without using lots of memcpy()? Driver: programming a fixed color cube palette, then use RGB332. fbcon/fbdev emulation: RGB332 support must be added I think. But both argb888 and rgb565 are supported today, so it should not be hard to find the places where you have to add some code to handle RGB332 too. > > Acceleration is harder. The scroll acceleration had issues nobody > > addressed for years, and on modern hardware it is simply not used, which > > is probably the reason nobody stepped up fixing things and it ended up > > being dropped. > > The DRM layer doesn't use scroll acceleration. > More than 30 other existing fbdev drivers use it. Yes. The world shifted from 2d acceleration to 3d acceleration. Modern hardware simply has no classic blitter any more. Which is a problem when it comes to keeping scroll acceleration alive, it is already a very niche use case and it will only become worse ... > > Bringing it back is much more work than just reverting the commits removing it. > > Reverting those commits have no effect on DRM's usage of fbcon. > But reverting those commits bring back scroll acceleration for all others. > I'm trying to find out which patches did apparently fixed such issues > for the REDRAW case. If you have a pointer it would be helpful. IIRC the code had a bunch of races and syzkaller flagged problems. I didn't follow very closely though. take care, Gerd
On 1/18/22 09:54, Helge Deller wrote: > On 1/18/22 09:38, Jani Nikula wrote: >> On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote: >>> On 1/17/22 22:40, Jani Nikula wrote: >>>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>> Seems like few people read linux-fbdev these days. >>>> >>>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel >>>> also? >>> >>> Doesn't seem like much traffic - which IMHO is OK for such a tree with >>> mostly just maintenance patches. >>> >>>> Do we still need a separate linux-fbdev mailing list at all? >>> >>> Yes. I want to have it seperate of dri-devel. >>> Actually I'd prefer to drop dri-devel from the list where patches >>> for fbdev are sent... >> >> Disagreed. If anything, this thread shows we can't have fbdev and drm in >> silos of their own. > > Patches to fbdev usually don't affect DRM. Patches for fbdev drivers don't usually affect DRM but that's not the case for patches to fbdev core and fbcon as you and others mentioned. > Patches which affect DRM needs to through to dri-devel. And how would people know which ones need to go through dri-devel ? Are you planning to add another entry to MAINTAINERS for fbdev core/fbcon ? > In addition this would take the burden of the dri-developers to receive > unrelated fbdev driver updates and patches. > In my opinion having fbdev patches in the dri-devel mailing list isn't a big burden, but rather getting people to review and push say patches. Since you are volunteering for the latter, that should improve things. I still fail to see the benefit of doing that split, same for having a separate fbdev tree. Using drm-misc only have advantages, among other things providing redundancy in cases that a maintainer isn't available for a period of time. Best regards,
Hi Javier, On Tue, Jan 18, 2022 at 10:33 AM Javier Martinez Canillas <javierm@redhat.com> wrote: > On 1/18/22 09:54, Helge Deller wrote: > > On 1/18/22 09:38, Jani Nikula wrote: > >> On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote: > >>> On 1/17/22 22:40, Jani Nikula wrote: > >>>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote: > >>>>> Seems like few people read linux-fbdev these days. > >>>> > >>>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel > >>>> also? > >>> > >>> Doesn't seem like much traffic - which IMHO is OK for such a tree with > >>> mostly just maintenance patches. > >>> > >>>> Do we still need a separate linux-fbdev mailing list at all? > >>> > >>> Yes. I want to have it seperate of dri-devel. > >>> Actually I'd prefer to drop dri-devel from the list where patches > >>> for fbdev are sent... > >> > >> Disagreed. If anything, this thread shows we can't have fbdev and drm in > >> silos of their own. > > > > Patches to fbdev usually don't affect DRM. > > Patches for fbdev drivers don't usually affect DRM but that's not the > case for patches to fbdev core and fbcon as you and others mentioned. > > > Patches which affect DRM needs to through to dri-devel. > > And how would people know which ones need to go through dri-devel ? Are > you planning to add another entry to MAINTAINERS for fbdev core/fbcon ? Those are nicely contained in drivers/video/fbdev/core/, so an entry in MAINTAINERS listing both linux-fbdev and dri-devel would do. > > In addition this would take the burden of the dri-developers to receive > > unrelated fbdev driver updates and patches. > > In my opinion having fbdev patches in the dri-devel mailing list isn't > a big burden, but rather getting people to review and push say patches. > > Since you are volunteering for the latter, that should improve things. > > I still fail to see the benefit of doing that split, same for having a > separate fbdev tree. Using drm-misc only have advantages, among other > things providing redundancy in cases that a maintainer isn't available > for a period of time. The above is the point of view from a DRM developer? For an fbdev developer, the burden to receive unrelated DRM driver updates and patches would be significant. The first page of https://lore.kernel.org/dri-devel/ goes back to yesterday. The first page of https://lore.kernel.org/linux-fbdev/ goes back to Nov 30th. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote: > On Mon, 17 Jan 2022 19:47:39 +0100 > Sven Schnelle <svens@stackframe.org> wrote: > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there > > a dmesg with 919 lines one the text console took about 2s to display. In > > x11, i measure 22ms. This might be unfair because encoding might be > > different, but i cannot confirm the 'memcpy' is faster than hardware > > blitting' point. I think if that would be the case, no-one would care > > about 2D acceleration. > > I think that is an extremely unfair comparison, because a graphical > terminal app is not going to render every line of text streamed to it. > It probably renders only the final view alone if you simply run > 'dmesg', skipping the first 800-900 lines completely. Probably more like "render on every vblank", but yes, unlike fbcon it surely wouldn't render every single character sent to the terminal. Also acceleration on modern hardware is more like "compose window content using the 3d engine" than "use 2d blitter to scroll the window". > Maybe fbcon should do the same when presented with a flood of text, > but I don't know how or why it works like it works. fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of doing it synchronously. take care, Gerd
Hi Michel, Michel Dänzer <michel.daenzer@mailbox.org> writes: > On 2022-01-17 19:47, Sven Schnelle wrote: >> >>> * There's no new development in fbdev and there are no new >>> drivers. Everyone works on DRM, which is better in most >>> regards. The consequence is that userspace is slowly loosing the >>> ability to use fbdev. >> >> That might be caused by the fact that no new drivers are accepted for >> fbdev. I wrote a driver for the HP Visualize FX5/10 cards end of last >> year which was rejected for inclusion into fbdev[1]. >> >> Based on your recommendation i re-wrote the whole thing in DRM. This >> works but has several drawbacks: >> >> - no modesetting. With fbdev, i can nicely switch resolutions with >> fbset. That doesn't work, and i've been told that this is not supported[2] >> >> - It is *much* slower than fbset with hardware blitting. I would have to >> dig out the numbers, but it's in the ratio of 1:15. The nice thing >> with fbdev blitting is that i get an array of pixels and the >> foreground/background colors all of these these pixels should have. >> With the help of the hardware blitting, i can write 32 pixels at once >> with every 32-bit transfer. >> >> With DRM, the closest i could find was DRM_FORMAT_C8, which means one >> byte per pixel. So i can put 4 pixels into one 32-bit transfer. >> >> fbdev also clears the lines with hardware blitting, which is much >> faster than clearing it with memcpy. >> >> Based on your recommendation i also verified that pci coalescing is >> enabled. >> >> These numbers are with DRM's unnatural scrolling behaviour - it seems >> to scroll several (text)lines at once if it takes to much time. I >> guess if DRM would scroll line by line it would be even slower. >> >> If DRM would add those things - hardware clearing of memory regions, >> hw blitting for text with a FG/BG color and modesetting i wouldn't >> care about fbdev at all. But right now, it's working way faster for me. > > A DRM driver can implement the same fbdev acceleration hooks as an fbdev driver. But i guess i can still only use the DRM_FORMAT_* encodings with that? What i need is a pixel bitmap with separate FG/BG colors. Is that possible? /Sven
On 1/18/22 10:16, Gerd Hoffmann wrote: > On Tue, Jan 18, 2022 at 09:20:43AM +0100, Helge Deller wrote: >> On 1/18/22 07:29, Gerd Hoffmann wrote: >>>> Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is >>>> currently unaccelerated and bound to Truecolour modes only, >>> >>> Yes. Adding support for formats beside argb8888 to the drm fbcon >>> emulation shouldn't be that much of a problem though. >> >> Really? Assuming a graphic card which runs with only 256 colors framebuffer >> is easily supported by DRM, and you can use fbcon without using lots of memcpy()? > > Driver: programming a fixed color cube palette, then use RGB332. > > fbcon/fbdev emulation: RGB332 support must be added I think. But both > argb888 and rgb565 are supported today, so it should not be hard to find > the places where you have to add some code to handle RGB332 too. I'd expect that that framework is provided by DRM developers if there is the wish to get rid of old fbdev and transition existing drivers over to use DRM. >>> Acceleration is harder. The scroll acceleration had issues nobody >>> addressed for years, and on modern hardware it is simply not used, which >>> is probably the reason nobody stepped up fixing things and it ended up >>> being dropped. >> >> The DRM layer doesn't use scroll acceleration. >> More than 30 other existing fbdev drivers use it. > > Yes. The world shifted from 2d acceleration to 3d acceleration. Modern > hardware simply has no classic blitter any more. Which is a problem > when it comes to keeping scroll acceleration alive, it is already a very > niche use case and it will only become worse ... For me it's Ok that the DRM drivers don't use 2d acceleration (as it is today with the arguments mentioned multiple times). But the patches broke existing fbdev acceleration which is available by the fbdev drivers. That's a big regression from point of fbdev. >>> Bringing it back is much more work than just reverting the commits removing it. >> >> Reverting those commits have no effect on DRM's usage of fbcon. >> But reverting those commits bring back scroll acceleration for all others. >> I'm trying to find out which patches did apparently fixed such issues >> for the REDRAW case. If you have a pointer it would be helpful. > > IIRC the code had a bunch of races and syzkaller flagged problems. > I didn't follow very closely though. That's sad. Nevertheless I wonder if the changes which were apparently done for the SCROLL_REDRAW case (on the higher level?) didn't also fixed the issues for SCROLL_MOVE. Helge
On 1/18/22 11:13, Helge Deller wrote: > On 1/18/22 10:16, Gerd Hoffmann wrote: >> On Tue, Jan 18, 2022 at 09:20:43AM +0100, Helge Deller wrote: >>> On 1/18/22 07:29, Gerd Hoffmann wrote: >>>>> Please correct me if I'm wrong, but text-console emulation/scrolling on DRM is >>>>> currently unaccelerated and bound to Truecolour modes only, >>>> >>>> Yes. Adding support for formats beside argb8888 to the drm fbcon >>>> emulation shouldn't be that much of a problem though. >>> >>> Really? Assuming a graphic card which runs with only 256 colors framebuffer >>> is easily supported by DRM, and you can use fbcon without using lots of memcpy()? >> >> Driver: programming a fixed color cube palette, then use RGB332. >> >> fbcon/fbdev emulation: RGB332 support must be added I think. But both >> argb888 and rgb565 are supported today, so it should not be hard to find >> the places where you have to add some code to handle RGB332 too. > > I'd expect that that framework is provided by DRM developers if there is the wish > to get rid of old fbdev and transition existing drivers over to use DRM. > >>>> Acceleration is harder. The scroll acceleration had issues nobody >>>> addressed for years, and on modern hardware it is simply not used, which >>>> is probably the reason nobody stepped up fixing things and it ended up >>>> being dropped. >>> >>> The DRM layer doesn't use scroll acceleration. >>> More than 30 other existing fbdev drivers use it. >> >> Yes. The world shifted from 2d acceleration to 3d acceleration. Modern >> hardware simply has no classic blitter any more. Which is a problem >> when it comes to keeping scroll acceleration alive, it is already a very >> niche use case and it will only become worse ... > > For me it's Ok that the DRM drivers don't use 2d acceleration (as it is today > with the arguments mentioned multiple times). > But the patches broke existing fbdev acceleration which is available by > the fbdev drivers. That's a big regression from point of fbdev. > >>>> Bringing it back is much more work than just reverting the commits removing it. >>> >>> Reverting those commits have no effect on DRM's usage of fbcon. >>> But reverting those commits bring back scroll acceleration for all others. >>> I'm trying to find out which patches did apparently fixed such issues >>> for the REDRAW case. If you have a pointer it would be helpful. >> >> IIRC the code had a bunch of races and syzkaller flagged problems. >> I didn't follow very closely though. > > That's sad. > Nevertheless I wonder if the changes which were apparently done for > the SCROLL_REDRAW case (on the higher level?) didn't also fixed the issues > for SCROLL_MOVE. I've just looked through all patches in drivers/video which were tagged with syzbot or syzkaller back to year 2005. The vast majority fixed the reported issues on a higher level, e.g. when screen is to be resized, or when font size is to be changed. The few ones which touched driver code fixed a real driver bug, e.g. by adding a check. NONE of those patches touched either the SCROLL_MOVE or the SCROLL_REDRAW case. That means, I see no reason why SCROLL_MOVE had to be ripped-out and just SCROLL_REDRAW had to be used instead, other than simply "it's not being used by DRM, so let's pull it out". The patches which removed SCROLL_MOVE support simply ignored the fact that SCROLL_MOVE is still heavily used by fbdev (non-DRM). I don't see a reason why the two patches which removed SCROLL_MOVE shouldn't be reverted. Or what am I missing? Helge
On Mon, Jan 17, 2022 at 10:55 PM Ilia Mirkin <imirkin@alum.mit.edu> wrote: > > On Mon, Jan 17, 2022 at 2:47 PM Helge Deller <deller@gmx.de> wrote: > > > > On 1/17/22 17:21, Helge Deller wrote: > > > On 1/17/22 16:58, Thomas Zimmermann wrote: > > >> Hi > > >> > > >> Am 17.01.22 um 16:42 schrieb Helge Deller: > > >>> [...] > > >>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines, > > >>>>> either when run on native hardware or in an emulator. > > >>>>> d) not break DRM development > > >>>>> > > >>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to > > >>>>> understand where the actual problems were and what's necessary to fix them. > > >>>>> > > >>>>> Helge > > >>>>> > > >>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de > > >> > > >> Seems like few people read linux-fbdev these days. > > >> I suggest to partly revert the patch to the point were performance > > >> gets better again. > > > Yes, *please*! > > > That would solve my biggest concern. > > > > > > As far as I can see that's only 2 commits to be reverted: > > > b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)" > > > 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next > > > > > > I think both were not related to any 0-day bug reports (but again, I might be wrong). > > > > I did some more checking... > > > > Both patches are not related to DRM, since no DRM driver sets the > > FBINFO_HWACCEL_COPYAREA or FBINFO_HWACCEL_FILLRECT flags. > > These used to be set by, at least, nouveau (which is a drm driver). > And yeah, console responsiveness is _way_ worse without that. People > keep pushing the messaging that it's the same speed to do it as > memcpy, but that's just not the case in my experience, on a pretty > bog-standard x86 desktop. The support got dumped, and it felt pretty > clear from the messaging at the time, "too bad". Would love to see it > come back. You need to add in a shadow buffer and it's fast. The problem is that the default fbcon sw code just replaces a hw blitter, and so does a _lot_ of memmoves reading from wc/uc memory. Which is an absolute disaster and results in a slideshow. Once you stop doing that the thing is pretty reasonable, which would also be what all the userspace sw compositors are doing. Fact that no one bothers to roll this out for most drivers just shows how little people care about accelerated fbcon. -Daniel > > Cheers, > > -ilia
On Tue, Jan 18, 2022 at 9:56 AM Helge Deller <deller@gmx.de> wrote: > > On 1/18/22 09:38, Jani Nikula wrote: > > On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote: > >> On 1/17/22 22:40, Jani Nikula wrote: > >>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote: > >>>> Seems like few people read linux-fbdev these days. > >>> > >>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel > >>> also? > >> > >> Doesn't seem like much traffic - which IMHO is OK for such a tree with > >> mostly just maintenance patches. > >> > >>> Do we still need a separate linux-fbdev mailing list at all? > >> > >> Yes. I want to have it seperate of dri-devel. > >> Actually I'd prefer to drop dri-devel from the list where patches > >> for fbdev are sent... > > > > Disagreed. If anything, this thread shows we can't have fbdev and drm in > > silos of their own. > > Patches to fbdev usually don't affect DRM. > Patches which affect DRM needs to through to dri-devel. > In addition this would take the burden of the dri-developers to receive > unrelated fbdev driver updates and patches. I added dri-devel for fbdev because stuff landed that shouldn't have. Let's not remove that, because the amount of patches for fbdev which arent relevant for drm drivers is pretty much nothing. I really don't like the idea that fbdev goes off again becoming a silo, just because it's too hard to wire through low-bit greyscale support. Which no I can't type for you, because I don't have such hw here. Everything where people cared enough for adding fbdev compat support for to actually write a patch is supported. If you do want a silo for fbdev then I think the only reasonable option is that we create a copy of the fbdev/fbcon code for drm (somewhat renamed), so that you can do the reverts without impacting drm drivers. But there will still be some overlap and minimal coordination, plus I'm not seeing anyone from the drm side volunteering for the sizeable amount of work. -Daniel > > Also, if the patches continue to get merged through drm-misc, they need > > to be sent to dri-devel. > > Helge
On Tue, Jan 18, 2022 at 10:54 AM Gerd Hoffmann <kraxel@redhat.com> wrote: > > On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote: > > On Mon, 17 Jan 2022 19:47:39 +0100 > > Sven Schnelle <svens@stackframe.org> wrote: > > > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there > > > a dmesg with 919 lines one the text console took about 2s to display. In > > > x11, i measure 22ms. This might be unfair because encoding might be > > > different, but i cannot confirm the 'memcpy' is faster than hardware > > > blitting' point. I think if that would be the case, no-one would care > > > about 2D acceleration. > > > > I think that is an extremely unfair comparison, because a graphical > > terminal app is not going to render every line of text streamed to it. > > It probably renders only the final view alone if you simply run > > 'dmesg', skipping the first 800-900 lines completely. > > Probably more like "render on every vblank", but yes, unlike fbcon it > surely wouldn't render every single character sent to the terminal. > > Also acceleration on modern hardware is more like "compose window > content using the 3d engine" than "use 2d blitter to scroll the window". > > > Maybe fbcon should do the same when presented with a flood of text, > > but I don't know how or why it works like it works. > > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of > doing it synchronously. Yeah, and if you use the shadow fb support in drm fbdev helpers, that's what you get. Maybe we should just make that the default, since that would also greatly simply stuff like modesetting support for fbdev. -Daniel
On Tue, Jan 18, 2022 at 9:41 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Jani, > > On Tue, Jan 18, 2022 at 9:38 AM Jani Nikula <jani.nikula@linux.intel.com> wrote: > > On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote: > > > On 1/17/22 22:40, Jani Nikula wrote: > > >> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > >>> Seems like few people read linux-fbdev these days. > > >> > > >> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel > > >> also? > > > > > > Doesn't seem like much traffic - which IMHO is OK for such a tree with > > > mostly just maintenance patches. > > > > > >> Do we still need a separate linux-fbdev mailing list at all? > > > > > > Yes. I want to have it seperate of dri-devel. > > > Actually I'd prefer to drop dri-devel from the list where patches > > > for fbdev are sent... > > > > Disagreed. If anything, this thread shows we can't have fbdev and drm in > > silos of their own. > > Unless DRM drops fbdev support. Isn't that the long-term plan anyway? No. There's way too much old stuff still using the fbdev interface to do that. We've even done things like standardize the vblank wait ioctl, because people need that. There's some effort to make fbdev drivers like efifb obsolete, and there's been discussions to have a drm-native fbcon. But none of these are going to make fbdev on top of drm obsolete and something we can remove. Pretty sure at least not this decade. -Daniel > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
On 1/18/22 12:18, Daniel Vetter wrote: > On Tue, Jan 18, 2022 at 9:56 AM Helge Deller <deller@gmx.de> wrote: >> >> On 1/18/22 09:38, Jani Nikula wrote: >>> On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote: >>>> On 1/17/22 22:40, Jani Nikula wrote: >>>>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>>> Seems like few people read linux-fbdev these days. >>>>> >>>>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel >>>>> also? >>>> >>>> Doesn't seem like much traffic - which IMHO is OK for such a tree with >>>> mostly just maintenance patches. >>>> >>>>> Do we still need a separate linux-fbdev mailing list at all? >>>> >>>> Yes. I want to have it seperate of dri-devel. >>>> Actually I'd prefer to drop dri-devel from the list where patches >>>> for fbdev are sent... >>> >>> Disagreed. If anything, this thread shows we can't have fbdev and drm in >>> silos of their own. >> >> Patches to fbdev usually don't affect DRM. >> Patches which affect DRM needs to through to dri-devel. >> In addition this would take the burden of the dri-developers to receive >> unrelated fbdev driver updates and patches. > > I added dri-devel for fbdev because stuff landed that shouldn't have. > Let's not remove that, because the amount of patches for fbdev which > arent relevant for drm drivers is pretty much nothing. I'm fine with keeping both lists mentioned in the MAINTAINERS file. It was a proposal and I understand you want to keep it. Ok for me. > I really don't like the idea that fbdev goes off again becoming a > silo, just because it's too hard to wire through low-bit greyscale > support. Which no I can't type for you, because I don't have such hw > here. > > Everything where people cared enough for adding fbdev compat support > for to actually write a patch is supported. > > If you do want a silo for fbdev then I think the only reasonable > option is that we create a copy of the fbdev/fbcon code for drm > (somewhat renamed), so that you can do the reverts without impacting > drm drivers. I don't see *any impact* on drm drivers at all if both patches would be reverted now. > But there will still be some overlap and minimal > coordination, plus I'm not seeing anyone from the drm side > volunteering for the sizeable amount of work. I wonder why you don't want to give it a try? My current proposal is to revert those two changes. Reverting them does not affect DRM code. Both DRM and some fbdev drivers still share excactly the same code paths in the SCROLL_REDRAW case. In addition there are some fbdev drivers which provide 2D support and instead allow SCROLL_MOVE. That's it. Currently I don't know which other cleanups or refactorings of fbcon are planned from DRM side, but I'm sure there is a easy way to keep both supported. If it then really turns out that it's not possible we can decide then how to continue. Helge > -Daniel > >>> Also, if the patches continue to get merged through drm-misc, they need >>> to be sent to dri-devel. >> >> Helge > > >
On Tue, Jan 18, 2022 at 9:10 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Gerd, > > On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann <kraxel@redhat.com> wrote: > > Also note that using a shadow framebuffer allows to decouple fbcon > > updates and scanout framebuffer updates. Can be used to speed up > > things without depending on the 2d blitter. > > Assuming accesses to the shadow frame buffer are faster than accesses > to the scanout frame buffer. While this is true on modern hardware, > this is not the case on all hardware. Especially if the shadow frame > buffer has a higher depth (XRGB8888) than the scanout frame buffer > (e.g. Cn)... > > The funny thing is that the systems we are interested in, once used > to be known for their graphics capabilities and/or performance... That's just a pure strawman. No one is forcing you to run your shadow buffer with xrgb8888. You can already do C8, any any other C1 is a few lines of code. Which I can't type for you, because I don't have such high performance hardware, but if someone would have spent hacking instead of typing mails any time this came up the past few years, we'd have it long ago. It's really not hard. Same goes for modesetting support in the fbdev emulation layer (that's a bit more work, but really not much) and really anything. And we do actually merge additions in the emulation support pretty quickly. If they show up. -Daniel > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
Hi, > > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of > > doing it synchronously. > > Yeah, and if you use the shadow fb support in drm fbdev helpers, > that's what you get. Maybe we should just make that the default, since > that would also greatly simply stuff like modesetting support for > fbdev. Yep, that helps of course. I was thinking more about the chars + attrs + font -> framebuffer step in the fbcon rendering pipeline though where one could do something simliar to save even more cpu cycles. take care, Gerd
On Tuesday, January 18th, 2022 at 12:41, Daniel Vetter <daniel@ffwll.ch> wrote: > On Tue, Jan 18, 2022 at 9:41 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > Hi Jani, > > > > On Tue, Jan 18, 2022 at 9:38 AM Jani Nikula <jani.nikula@linux.intel.com> wrote: > > > On Mon, 17 Jan 2022, Helge Deller <deller@gmx.de> wrote: > > > > On 1/17/22 22:40, Jani Nikula wrote: > > > >> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > > >>> Seems like few people read linux-fbdev these days. > > > >> > > > >> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel > > > >> also? > > > > > > > > Doesn't seem like much traffic - which IMHO is OK for such a tree with > > > > mostly just maintenance patches. > > > > > > > >> Do we still need a separate linux-fbdev mailing list at all? > > > > > > > > Yes. I want to have it seperate of dri-devel. > > > > Actually I'd prefer to drop dri-devel from the list where patches > > > > for fbdev are sent... > > > > > > Disagreed. If anything, this thread shows we can't have fbdev and drm in > > > silos of their own. > > > > Unless DRM drops fbdev support. Isn't that the long-term plan anyway? > > No. There's way too much old stuff still using the fbdev interface to > do that. We've even done things like standardize the vblank wait > ioctl, because people need that. Kind of related: I wonder, could we document somewhere that fbdev is a deprecated uAPI? ie. new user-space shouldn't use it and should prefer DRM. I don't see that mentioned anywhere, although it seems like it's the consensus among all kernel developers I've talked to.
Hi, > > fbcon/fbdev emulation: RGB332 support must be added I think. But both > > argb888 and rgb565 are supported today, so it should not be hard to find > > the places where you have to add some code to handle RGB332 too. > > I'd expect that that framework is provided by DRM developers if there is the wish > to get rid of old fbdev and transition existing drivers over to use DRM. Good luck with that. Asking people to code up stuff they can't even test due to lack of hardware isn't going to fly very well. > > Yes. The world shifted from 2d acceleration to 3d acceleration. Modern > > hardware simply has no classic blitter any more. Which is a problem > > when it comes to keeping scroll acceleration alive, it is already a very > > niche use case and it will only become worse ... > > For me it's Ok that the DRM drivers don't use 2d acceleration (as it is today > with the arguments mentioned multiple times). > But the patches broke existing fbdev acceleration which is available by > the fbdev drivers. That's a big regression from point of fbdev. Keeping it alive and working will be a tough challenge. 2d acceleration is a thing of the past and the number of people which are able and willing to put effort into supporting it will only decline. It has been a problem for a while already, basically it was dropped due to lack of support ... take care, Gerd
Hi Am 17.01.22 um 19:47 schrieb Sven Schnelle: > Hi Thomas, > > Thomas Zimmermann <tzimmermann@suse.de> writes: > >> Hi >> >> Am 14.01.22 um 19:11 schrieb Helge Deller: >>> The fbdev layer is orphaned, but seems to need some care. >>> So I'd like to step up as new maintainer. >>> Signed-off-by: Helge Deller <deller@gmx.de> >> >> First of all, thank you for stepping up to maintain the fbdev >> codebase. It really needs someone actively looking after it. >> >> And now comes the BUT. >> >> I want to second everything said by Danial and Javier. In addition to >> purely organizational topics (trees, PRs, etc), there are a number of >> inherit problems with fbdev. >> >> * It's 90s technology. Neither does it fit today's userspace, not >> hardware. If you have more than just the most trivial of graphical >> output fbdev isn't for you. >> >> * There's no new development in fbdev and there are no new >> drivers. Everyone works on DRM, which is better in most >> regards. The consequence is that userspace is slowly loosing the >> ability to use fbdev. > > That might be caused by the fact that no new drivers are accepted for And that is caused by the fact that fbdev is nowhere up to todays requirements. > fbdev. I wrote a driver for the HP Visualize FX5/10 cards end of last > year which was rejected for inclusion into fbdev[1]. Yep, I was hoping for a reply. > > Based on your recommendation i re-wrote the whole thing in DRM. This > works but has several drawbacks: > > - no modesetting. With fbdev, i can nicely switch resolutions with > fbset. That doesn't work, and i've been told that this is not supported[2] I didn't say that we're not going to support it at all. It's just not supported at the momont. vmwgfx has modesetting code that can serve as starting point. > > - It is *much* slower than fbset with hardware blitting. I would have to > dig out the numbers, but it's in the ratio of 1:15. The nice thing > with fbdev blitting is that i get an array of pixels and the > foreground/background colors all of these these pixels should have. > With the help of the hardware blitting, i can write 32 pixels at once > with every 32-bit transfer. For comparison, how fast is fbdev with plain memcpy() and memset()? > > With DRM, the closest i could find was DRM_FORMAT_C8, which means one > byte per pixel. So i can put 4 pixels into one 32-bit transfer. IIRC the hardware only supported 8-bit palette colors, so C8 was the correct choice. Otherwise, you can add new formats and add them to the console. > > fbdev also clears the lines with hardware blitting, which is much > faster than clearing it with memcpy. > > Based on your recommendation i also verified that pci coalescing is > enabled. > > These numbers are with DRM's unnatural scrolling behaviour - it seems > to scroll several (text)lines at once if it takes to much time. I > guess if DRM would scroll line by line it would be even slower. > > If DRM would add those things - hardware clearing of memory regions, > hw blitting for text with a FG/BG color and modesetting i wouldn't > care about fbdev at all. But right now, it's working way faster for me. I admit that your hardware is at the edge of what DRM currently supports. But I've used some of the DRM stuff on Athlon XPs with PCI graphics. While the performance wasn't good, it was far from unusable. I guess you used GEM SHMEM for memory buffers. fbdev and mmap with shmem pages use some of the same bits in struct page, so shmem cannot mmap it's pages directly. We have to use an additional shadow buffer. Any display update goes from the shadow buffer into the shmem buffer and into the videoram. That's two memcpys. This can be reduced to one memcpy, but we never had the requirement to do so. There's also potential for reducing the amount of page mappings/unmappings with gem shmem. And DRM supports shadow buffers, virtual screen sizes and damage handling in DRM. A sophisticated driver might be able to use shadow buffering, damage handling and hardware panning to reduce the amount of screen updates to a minimum. Until these things are fixed, adding hardware blitting doesn't really make sense IMHO. As with other things, we didn't have a requirement for all these optimizations so far. A usually good approach to improve the sitution is to get a basic driver merged and then address the problems one by one. Best regards Thomas > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there > a dmesg with 919 lines one the text console took about 2s to display. In > x11, i measure 22ms. This might be unfair because encoding might be > different, but i cannot confirm the 'memcpy' is faster than hardware > blitting' point. I think if that would be the case, no-one would care > about 2D acceleration. > > Don't get me wrong, i'm not saying there's no reason for DRM. I fully > understand why it exists and think it's a good way to go. But for system > where a (fast) local console is required without X11, fbdev might be the > better choice at the moment. > > Regards > Sven > > [1] https://lore.kernel.org/all/87ee7qvcc7.fsf@x1.stackframe.org/T/#m57cdea83608fc78bfc6c2e76eb037bf82017b302 > [2] https://lore.kernel.org/all/87ee7qvcc7.fsf@x1.stackframe.org/T/#m46a52815036a958f6a11d2f3f62e1340a09bd981 >
Hi Am 17.01.22 um 17:21 schrieb Helge Deller: > On 1/17/22 16:58, Thomas Zimmermann wrote: >> Hi >> >> Am 17.01.22 um 16:42 schrieb Helge Deller: >>> [...] >>>>> c) reintroduce the state where fbcon is fast on fbdev. This is important for non-DRM machines, >>>>> either when run on native hardware or in an emulator. >>>>> d) not break DRM development >>>>> >>>>> Especially regarding c) I complained in [1] and got no feedback. I really would like to >>>>> understand where the actual problems were and what's necessary to fix them. >>>>> >>>>> Helge >>>>> >>>>> [1] https://lore.kernel.org/r/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de >> >> Seems like few people read linux-fbdev these days. >> I suggest to partly revert the patch to the point were performance >> gets better again. If you want that, you should send a patch. Best regards Thomas > Yes, *please*! > That would solve my biggest concern. > > As far as I can see that's only 2 commits to be reverted: > b3ec8cdf457e - "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)" > 39aead8373b3 - "fbcon: Disable accelerated scrolling"for-next-next > > I think both were not related to any 0-day bug reports (but again, I might be wrong). > > Helge
Hi Am 18.01.22 um 09:10 schrieb Geert Uytterhoeven: > Hi Gerd, > > On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann <kraxel@redhat.com> wrote: >> Also note that using a shadow framebuffer allows to decouple fbcon >> updates and scanout framebuffer updates. Can be used to speed up >> things without depending on the 2d blitter. > > Assuming accesses to the shadow frame buffer are faster than accesses > to the scanout frame buffer. While this is true on modern hardware, > this is not the case on all hardware. Especially if the shadow frame > buffer has a higher depth (XRGB8888) than the scanout frame buffer > (e.g. Cn)... > > The funny thing is that the systems we are interested in, once used > to be known for their graphics capabilities and/or performance... What I still don't understand: why are you so keen on maintaining an interface that only serves the console? Nothing else uses fbdev these days. Why not improve DRM/userspace to the point where it fits your requirements? Long-term, the latter would make a lot more sense. Best regards Thomas > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
On Tuesday, January 18th, 2022 at 15:23, Thomas Zimmermann <tzimmermann@suse.de> wrote: > Am 18.01.22 um 09:10 schrieb Geert Uytterhoeven: > > Hi Gerd, > > > > On Tue, Jan 18, 2022 at 7:30 AM Gerd Hoffmann <kraxel@redhat.com> wrote: > >> Also note that using a shadow framebuffer allows to decouple fbcon > >> updates and scanout framebuffer updates. Can be used to speed up > >> things without depending on the 2d blitter. > > > > Assuming accesses to the shadow frame buffer are faster than accesses > > to the scanout frame buffer. While this is true on modern hardware, > > this is not the case on all hardware. Especially if the shadow frame > > buffer has a higher depth (XRGB8888) than the scanout frame buffer > > (e.g. Cn)... > > > > The funny thing is that the systems we are interested in, once used > > to be known for their graphics capabilities and/or performance... > > What I still don't understand: why are you so keen on maintaining an > interface that only serves the console? Nothing else uses fbdev these > days. Why not improve DRM/userspace to the point where it fits your > requirements? Long-term, the latter would make a lot more sense. +1 If you need any help with adapting user-space, feel free to ping me. I'd be interested in discussing, providing feedback and potentially user-space patches.
On Tue, 18 Jan 2022 10:53:52 +0100 Gerd Hoffmann <kraxel@redhat.com> wrote: > On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote: > > On Mon, 17 Jan 2022 19:47:39 +0100 > > Sven Schnelle <svens@stackframe.org> wrote: > > > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there > > > a dmesg with 919 lines one the text console took about 2s to display. In > > > x11, i measure 22ms. This might be unfair because encoding might be > > > different, but i cannot confirm the 'memcpy' is faster than hardware > > > blitting' point. I think if that would be the case, no-one would care > > > about 2D acceleration. > > > > I think that is an extremely unfair comparison, because a graphical > > terminal app is not going to render every line of text streamed to it. > > It probably renders only the final view alone if you simply run > > 'dmesg', skipping the first 800-900 lines completely. > > Probably more like "render on every vblank", but yes, unlike fbcon it > surely wouldn't render every single character sent to the terminal. Yes, and since 1k lines of dmesg is such little data, I would guess even an old machine can chew that up in much less than one refresh period until it needs to draw, so there is only going to be one or two screen updates to be drawn. Also, since X11 does not have vblank or frame boundaries in the protocol, a terminal emulator app will do render throttling somehow else. Maybe when it temporarily exhausts input and a timer as a deadline in case input just keeps on flooding, would be my wild guess. Thanks, pq
Hi Gerd, On Thu, Jan 20, 2022 at 4:29 AM Gerd Hoffmann <kraxel@redhat.com> wrote: > On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote: > > On Mon, 17 Jan 2022 19:47:39 +0100 > > Sven Schnelle <svens@stackframe.org> wrote: > > > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there > > > a dmesg with 919 lines one the text console took about 2s to display. In > > > x11, i measure 22ms. This might be unfair because encoding might be > > > different, but i cannot confirm the 'memcpy' is faster than hardware > > > blitting' point. I think if that would be the case, no-one would care > > > about 2D acceleration. > > > > I think that is an extremely unfair comparison, because a graphical > > terminal app is not going to render every line of text streamed to it. > > It probably renders only the final view alone if you simply run > > 'dmesg', skipping the first 800-900 lines completely. > > Probably more like "render on every vblank", but yes, unlike fbcon it > surely wouldn't render every single character sent to the terminal. > > Also acceleration on modern hardware is more like "compose window > content using the 3d engine" than "use 2d blitter to scroll the window". > > > Maybe fbcon should do the same when presented with a flood of text, > > but I don't know how or why it works like it works. > > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of > doing it synchronously. Hopefully only the parts of the screen which need a redraw? Not all displays can be updated that fast. For a "modern" example, see https://patchwork.freedesktop.org/series/93070/. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Thu, Jan 20, 2022 at 10:06 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Gerd, > > On Thu, Jan 20, 2022 at 4:29 AM Gerd Hoffmann <kraxel@redhat.com> wrote: > > On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote: > > > On Mon, 17 Jan 2022 19:47:39 +0100 > > > Sven Schnelle <svens@stackframe.org> wrote: > > > > > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there > > > > a dmesg with 919 lines one the text console took about 2s to display. In > > > > x11, i measure 22ms. This might be unfair because encoding might be > > > > different, but i cannot confirm the 'memcpy' is faster than hardware > > > > blitting' point. I think if that would be the case, no-one would care > > > > about 2D acceleration. > > > > > > I think that is an extremely unfair comparison, because a graphical > > > terminal app is not going to render every line of text streamed to it. > > > It probably renders only the final view alone if you simply run > > > 'dmesg', skipping the first 800-900 lines completely. > > > > Probably more like "render on every vblank", but yes, unlike fbcon it > > surely wouldn't render every single character sent to the terminal. > > > > Also acceleration on modern hardware is more like "compose window > > content using the 3d engine" than "use 2d blitter to scroll the window". > > > > > Maybe fbcon should do the same when presented with a flood of text, > > > but I don't know how or why it works like it works. > > > > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of > > doing it synchronously. > > Hopefully only the parts of the screen which need a redraw? > > Not all displays can be updated that fast. For a "modern" example, see > https://patchwork.freedesktop.org/series/93070/. drm does damage tracking throughout the stack, e.g. https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#damage-tracking-properties And unlike fbdev, it's explicit (so less overhead since userspace generally knows what it's drawn) and doesn't rely on page fault intercepting and fun stuff like that. Like do people actually know what drm can and cannot do, or would that take out all the fun? -Daniel > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
Hi, > > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of > > doing it synchronously. > > Hopefully only the parts of the screen which need a redraw? Sure. drm fbdev emulation with shadow framebuffer tracks changes and only flushes dirty areas to the real framebuffer. fbcon could do the same when implementing lazy rendering, keeping track of the chars/attrs which did actually change and only render those to the (emulated or real) fbdev. take care, Gerd
Hi Daniel, On Thu, Jan 20, 2022 at 12:33 PM Daniel Vetter <daniel@ffwll.ch> wrote: > On Thu, Jan 20, 2022 at 10:06 AM Geert Uytterhoeven > <geert@linux-m68k.org> wrote: > > On Thu, Jan 20, 2022 at 4:29 AM Gerd Hoffmann <kraxel@redhat.com> wrote: > > > On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote: > > > > On Mon, 17 Jan 2022 19:47:39 +0100 > > > > Sven Schnelle <svens@stackframe.org> wrote: > > > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there > > > > > a dmesg with 919 lines one the text console took about 2s to display. In > > > > > x11, i measure 22ms. This might be unfair because encoding might be > > > > > different, but i cannot confirm the 'memcpy' is faster than hardware > > > > > blitting' point. I think if that would be the case, no-one would care > > > > > about 2D acceleration. > > > > > > > > I think that is an extremely unfair comparison, because a graphical > > > > terminal app is not going to render every line of text streamed to it. > > > > It probably renders only the final view alone if you simply run > > > > 'dmesg', skipping the first 800-900 lines completely. > > > > > > Probably more like "render on every vblank", but yes, unlike fbcon it > > > surely wouldn't render every single character sent to the terminal. > > > > > > Also acceleration on modern hardware is more like "compose window > > > content using the 3d engine" than "use 2d blitter to scroll the window". > > > > > > > Maybe fbcon should do the same when presented with a flood of text, > > > > but I don't know how or why it works like it works. > > > > > > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of > > > doing it synchronously. > > > > Hopefully only the parts of the screen which need a redraw? > > > > Not all displays can be updated that fast. For a "modern" example, see > > https://patchwork.freedesktop.org/series/93070/. > > drm does damage tracking throughout the stack, e.g. > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#damage-tracking-properties > > And unlike fbdev, it's explicit (so less overhead since userspace > generally knows what it's drawn) and doesn't rely on page fault > intercepting and fun stuff like that. My reply was to a paragraph about rendering text by fbcon, not about userspace rendering graphics. > Like do people actually know what drm can and cannot do, or would that > take out all the fun? ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Thu, Jan 20, 2022 at 1:13 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Daniel, > > On Thu, Jan 20, 2022 at 12:33 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > On Thu, Jan 20, 2022 at 10:06 AM Geert Uytterhoeven > > <geert@linux-m68k.org> wrote: > > > On Thu, Jan 20, 2022 at 4:29 AM Gerd Hoffmann <kraxel@redhat.com> wrote: > > > > On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote: > > > > > On Mon, 17 Jan 2022 19:47:39 +0100 > > > > > Sven Schnelle <svens@stackframe.org> wrote: > > > > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there > > > > > > a dmesg with 919 lines one the text console took about 2s to display. In > > > > > > x11, i measure 22ms. This might be unfair because encoding might be > > > > > > different, but i cannot confirm the 'memcpy' is faster than hardware > > > > > > blitting' point. I think if that would be the case, no-one would care > > > > > > about 2D acceleration. > > > > > > > > > > I think that is an extremely unfair comparison, because a graphical > > > > > terminal app is not going to render every line of text streamed to it. > > > > > It probably renders only the final view alone if you simply run > > > > > 'dmesg', skipping the first 800-900 lines completely. > > > > > > > > Probably more like "render on every vblank", but yes, unlike fbcon it > > > > surely wouldn't render every single character sent to the terminal. > > > > > > > > Also acceleration on modern hardware is more like "compose window > > > > content using the 3d engine" than "use 2d blitter to scroll the window". > > > > > > > > > Maybe fbcon should do the same when presented with a flood of text, > > > > > but I don't know how or why it works like it works. > > > > > > > > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of > > > > doing it synchronously. > > > > > > Hopefully only the parts of the screen which need a redraw? > > > > > > Not all displays can be updated that fast. For a "modern" example, see > > > https://patchwork.freedesktop.org/series/93070/. > > > > drm does damage tracking throughout the stack, e.g. > > > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#damage-tracking-properties > > > > And unlike fbdev, it's explicit (so less overhead since userspace > > generally knows what it's drawn) and doesn't rely on page fault > > intercepting and fun stuff like that. > > My reply was to a paragraph about rendering text by fbcon, not about > userspace rendering graphics. Yeah, and ofc when I say "throughout the stack" this also includes the fbdev emulation, including the mmap intercepting with fbdev_defio and all that. They all get remapped to that damage tracking property, which drivers can then inspect using a bunch of helpers. But reading code&docs is too hard I guess, safer to assume it's just broken and not supported. -Daniel > > Like do people actually know what drm can and cannot do, or would that > > take out all the fun? > > ;-) > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
Hi Daniel, On Thu, Jan 20, 2022 at 1:33 PM Daniel Vetter <daniel@ffwll.ch> wrote: > On Thu, Jan 20, 2022 at 1:13 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Thu, Jan 20, 2022 at 12:33 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > > On Thu, Jan 20, 2022 at 10:06 AM Geert Uytterhoeven > > > <geert@linux-m68k.org> wrote: > > > > On Thu, Jan 20, 2022 at 4:29 AM Gerd Hoffmann <kraxel@redhat.com> wrote: > > > > > On Tue, Jan 18, 2022 at 10:33:23AM +0200, Pekka Paalanen wrote: > > > > > > On Mon, 17 Jan 2022 19:47:39 +0100 > > > > > > Sven Schnelle <svens@stackframe.org> wrote: > > > > > > > I also tested the speed on my Thinkpad X1 with Intel graphics, and there > > > > > > > a dmesg with 919 lines one the text console took about 2s to display. In > > > > > > > x11, i measure 22ms. This might be unfair because encoding might be > > > > > > > different, but i cannot confirm the 'memcpy' is faster than hardware > > > > > > > blitting' point. I think if that would be the case, no-one would care > > > > > > > about 2D acceleration. > > > > > > > > > > > > I think that is an extremely unfair comparison, because a graphical > > > > > > terminal app is not going to render every line of text streamed to it. > > > > > > It probably renders only the final view alone if you simply run > > > > > > 'dmesg', skipping the first 800-900 lines completely. > > > > > > > > > > Probably more like "render on every vblank", but yes, unlike fbcon it > > > > > surely wouldn't render every single character sent to the terminal. > > > > > > > > > > Also acceleration on modern hardware is more like "compose window > > > > > content using the 3d engine" than "use 2d blitter to scroll the window". > > > > > > > > > > > Maybe fbcon should do the same when presented with a flood of text, > > > > > > but I don't know how or why it works like it works. > > > > > > > > > > fbcon could do the same, i.e. render to fbdev in a 60Hz timer instead of > > > > > doing it synchronously. > > > > > > > > Hopefully only the parts of the screen which need a redraw? > > > > > > > > Not all displays can be updated that fast. For a "modern" example, see > > > > https://patchwork.freedesktop.org/series/93070/. > > > > > > drm does damage tracking throughout the stack, e.g. > > > > > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#damage-tracking-properties > > > > > > And unlike fbdev, it's explicit (so less overhead since userspace > > > generally knows what it's drawn) and doesn't rely on page fault > > > intercepting and fun stuff like that. > > > > My reply was to a paragraph about rendering text by fbcon, not about > > userspace rendering graphics. > > Yeah, and ofc when I say "throughout the stack" this also includes the > fbdev emulation, including the mmap intercepting with fbdev_defio and > all that. They all get remapped to that damage tracking property, > which drivers can then inspect using a bunch of helpers. And I really meant the text rendering part, not the copy of the shadow buffer after the rendering. > But reading code&docs is too hard I guess, safer to assume it's just > broken and not supported. Don't worry, I'm actually writing a larger rebuttal _and_ code... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi, > What I still don't understand: why are you so keen on maintaining an > interface that only serves the console? Nothing else uses fbdev these days. > Why not improve DRM/userspace to the point where it fits your requirements? > Long-term, the latter would make a lot more sense. And note that it is *much* easier to write drm drivers these days. We got alot of helpers, we got generic fbdev emulation and more. If you are curious just compare the initial commit of the bochs drm driver with the current code. Initially the driver had to manage ttm and fbdev and whatnot else. These days writing a (non-accelerated) drm driver is basically some boilerplate picking the helpers which work best for your hardware, the code to actually program the hardware and that's it. The "new drivers should be drm" policy exists for years already btw, exactly because of the unfixable fbdev API limitations. The bochs drm was a fbdev driver initially. Never merged. Got rewritten as drm driver and that was merged instead. In 2013, almost a decade ago. And, yes, it very well might be that drm misses some piece here and there for specific hardware, such as fbdev emulation not supporting rgb332. But I fully agree with Thomas here: Improving drm is probably a much better way to spend your time. drm is where the development happens. fbdev is only kept alive. take care, Gerd
On Fri, Jan 21, 2022 at 9:46 AM Gerd Hoffmann <kraxel@redhat.com> wrote: > > Hi, > > > What I still don't understand: why are you so keen on maintaining an > > interface that only serves the console? Nothing else uses fbdev these days. > > Why not improve DRM/userspace to the point where it fits your requirements? > > Long-term, the latter would make a lot more sense. > > And note that it is *much* easier to write drm drivers these days. > We got alot of helpers, we got generic fbdev emulation and more. > > If you are curious just compare the initial commit of the bochs drm > driver with the current code. Initially the driver had to manage ttm > and fbdev and whatnot else. These days writing a (non-accelerated) drm > driver is basically some boilerplate picking the helpers which work best > for your hardware, the code to actually program the hardware and that's > it. > > The "new drivers should be drm" policy exists for years already btw, > exactly because of the unfixable fbdev API limitations. The bochs drm > was a fbdev driver initially. Never merged. Got rewritten as drm > driver and that was merged instead. In 2013, almost a decade ago. > > And, yes, it very well might be that drm misses some piece here and > there for specific hardware, such as fbdev emulation not supporting > rgb332. But I fully agree with Thomas here: Improving drm is probably > a much better way to spend your time. drm is where the development > happens. fbdev is only kept alive. Just to clarify, since we had lots of smaller and bigger misunderstandings in the thread thus far: DRM_FORMAT_RGB332 exists, so drm support that already. The fbdev emulation doesn't yet, but all that's needed for that is filling out the code to remap the drm description to the fbdev format description for this case. Plus testing it all works ofc with fbcon and whatelse. Note that RGB332 is a bit more work than e.g. C4, since atm fbdev still uses only bpp to identify formats, so would need to be switch over to drm_fourcc first before adding anything which aliases with something existing (we have C8 already wired up). -Daniel
Hi Daniel, On Fri, Jan 21, 2022 at 9:55 AM Daniel Vetter <daniel@ffwll.ch> wrote: > Just to clarify, since we had lots of smaller and bigger > misunderstandings in the thread thus far: DRM_FORMAT_RGB332 exists, so > drm support that already. The fbdev emulation doesn't yet, but all > that's needed for that is filling out the code to remap the drm > description to the fbdev format description for this case. Plus > testing it all works ofc with fbcon and whatelse. Note that RGB332 is > a bit more work than e.g. C4, since atm fbdev still uses only bpp to > identify formats, so would need to be switch over to drm_fourcc first > before adding anything which aliases with something existing (we have > C8 already wired up). I doubt that RGB332 would be a bit more work than C4, as RGB332 is still 8 bpp, while C4 is less. To support C4, all DRM code that cannot handle format->cpp[0] < 1 or drm_format_info_block_width() > 1 has to be fixed first. On the plus side, I finally got my proof-of-concept Atari DRM driver working with fbcon on ARAnyM. Mapping /dev/fb0 from userspace doesn't work (fbtest SEGVs while reading from the mapped frame buffer). I don't know yet if this is a general issue without deferred I/O in v5.17-rc1, or a bug in the m68k MM code... So far it supports C8 only, but I hope to tackle C4 and monochrome soon. Whether the end result will be usable on real hardware is still to be seen, but at least I hope to get some DRM code written... Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Mon, Jan 24, 2022 at 7:39 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Daniel, > > On Fri, Jan 21, 2022 at 9:55 AM Daniel Vetter <daniel@ffwll.ch> wrote: > > Just to clarify, since we had lots of smaller and bigger > > misunderstandings in the thread thus far: DRM_FORMAT_RGB332 exists, so > > drm support that already. The fbdev emulation doesn't yet, but all > > that's needed for that is filling out the code to remap the drm > > description to the fbdev format description for this case. Plus > > testing it all works ofc with fbcon and whatelse. Note that RGB332 is > > a bit more work than e.g. C4, since atm fbdev still uses only bpp to > > identify formats, so would need to be switch over to drm_fourcc first > > before adding anything which aliases with something existing (we have > > C8 already wired up). > > I doubt that RGB332 would be a bit more work than C4, as RGB332 is still > 8 bpp, while C4 is less. To support C4, all DRM code that cannot > handle format->cpp[0] < 1 or drm_format_info_block_width() > 1 has to be > fixed first. Hm what's broken with it? Current code means it cannot support odd width for C4 (because to make C4 fit into bytes you need 2 pixels), but otherwise this should all work. Iirc we have formats with "5 pixels in 4 bytes" and fun stuff like that. Note that stride and also the actual window you scan out are all separate, so even if your hw needs an odd stride or you have an odd resolution it should still all work out for C4 with the existing infra. RGB322 is more work because in the fbdev code this aliases with bpp=8 which is C8, because no one has yet moved the fbdev emulation code forward into the drm_fourcc world. > On the plus side, I finally got my proof-of-concept Atari DRM driver > working with fbcon on ARAnyM. Mapping /dev/fb0 from userspace doesn't > work (fbtest SEGVs while reading from the mapped frame buffer). I don't > know yet if this is a general issue without deferred I/O in v5.17-rc1, > or a bug in the m68k MM code... > > So far it supports C8 only, but I hope to tackle C4 and monochrome soon. > Whether the end result will be usable on real hardware is still to be > seen, but at least I hope to get some DRM code written... Yay, this sounds interesting! -Daniel
Hi Daniel, On Thu, Jan 20, 2022 at 1:33 PM Daniel Vetter <daniel@ffwll.ch> wrote: > But reading code&docs is too hard I guess, safer to assume it's just > broken and not supported. I confirm there's lots of documentation (and even more code ;-), which is always great! But both are intimidating to me, and most of the documentation covers features I'm not interested in, as they're only applicable to fancy modern truecolor 3D-capable multi-buffer and multi-head hardware, while what I am looking for is usually not documented. E.g. I had a hard time to discover how color look-up tables work (gamma_{store,size}!), as this is not covered in https://docs.kernel.org/gpu/index.html, and none of the tinydrm drivers support CLUT modes. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Hi Am 24.01.22 um 19:38 schrieb Geert Uytterhoeven: > Hi Daniel, > > On Fri, Jan 21, 2022 at 9:55 AM Daniel Vetter <daniel@ffwll.ch> wrote: >> Just to clarify, since we had lots of smaller and bigger >> misunderstandings in the thread thus far: DRM_FORMAT_RGB332 exists, so >> drm support that already. The fbdev emulation doesn't yet, but all >> that's needed for that is filling out the code to remap the drm >> description to the fbdev format description for this case. Plus >> testing it all works ofc with fbcon and whatelse. Note that RGB332 is >> a bit more work than e.g. C4, since atm fbdev still uses only bpp to >> identify formats, so would need to be switch over to drm_fourcc first >> before adding anything which aliases with something existing (we have >> C8 already wired up). > > I doubt that RGB332 would be a bit more work than C4, as RGB332 is still > 8 bpp, while C4 is less. To support C4, all DRM code that cannot > handle format->cpp[0] < 1 or drm_format_info_block_width() > 1 has to be > fixed first. > > On the plus side, I finally got my proof-of-concept Atari DRM driver > working with fbcon on ARAnyM. Mapping /dev/fb0 from userspace doesn't > work (fbtest SEGVs while reading from the mapped frame buffer). I don't > know yet if this is a general issue without deferred I/O in v5.17-rc1, > or a bug in the m68k MM code... > > So far it supports C8 only, but I hope to tackle C4 and monochrome soon. > Whether the end result will be usable on real hardware is still to be > seen, but at least I hope to get some DRM code written... That sounds pretty cool. Best regards Thomas > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
On Mon, Jan 24, 2022 at 7:51 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Daniel, > > On Thu, Jan 20, 2022 at 1:33 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > But reading code&docs is too hard I guess, safer to assume it's just > > broken and not supported. > > I confirm there's lots of documentation (and even more code ;-), > which is always great! > But both are intimidating to me, and most of the documentation covers > features I'm not interested in, as they're only applicable to fancy > modern truecolor 3D-capable multi-buffer and multi-head hardware, while > what I am looking for is usually not documented. E.g. I had a hard > time to discover how color look-up tables work (gamma_{store,size}!), > as this is not covered in https://docs.kernel.org/gpu/index.html, > and none of the tinydrm drivers support CLUT modes. Hm yeah that part is a bit awkward since due to how Xorg works here the gamma table is abused to be the lookup table for C8. If we're adding piles of new Cx formats it might be worth it to structure this a bit better, e.g. (really just thinking on the spot here): - have a separate Cx lookup table blob in drm_plane_state (in theory you could have a different one on each plane and still have an overall gamma ramp on the crtc) - change the compat functions which map the legacy gamma ramp to redirect to the plane gamma ramp if the primary plane is set to Cx - bonus points for then correctly sizing the lookup table to match the number of bits in the Cx plane format But unfiddling this confusion properly is going to be tricky. I think just continuing the tradition we have for C8 and reusing the crtc gamma ramp for that is probably fine for now. And yes that's not documented, because when we fixed the docs for the entire degamm/CGM/gamma color correction pipeline Cx wasn't the top priority :-) Cheers, Daniel
diff --git a/MAINTAINERS b/MAINTAINERS index 5d0cd537803a..ce47dbc467cc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7583,11 +7583,12 @@ W: http://floatingpoint.sourceforge.net/emulator/index.html F: arch/x86/math-emu/ FRAMEBUFFER LAYER -L: dri-devel@lists.freedesktop.org +M: Helge Deller <deller@gmx.de> L: linux-fbdev@vger.kernel.org -S: Orphan +L: dri-devel@lists.freedesktop.org +S: Maintained Q: http://patchwork.kernel.org/project/linux-fbdev/list/ -T: git git://anongit.freedesktop.org/drm/drm-misc +T: git git://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git F: Documentation/fb/ F: drivers/video/ F: include/linux/fb.h
The fbdev layer is orphaned, but seems to need some care. So I'd like to step up as new maintainer. Signed-off-by: Helge Deller <deller@gmx.de>