But the work I do within fbdev is mostly for improving DRM.
Sure.
For the
other issues in this file, I don't think that matroxfb should even be
around any longer. Fbdev has been deprecated for a long time. But a
small number of drivers are still in use and we still need its
framebuffer console. So someone should either put significant effort
into maintaining fbdev, or it should be phased out. But neither is
happening.
You're wrong.
I'm not. I don't claim that these drivers are all broken. But fbdev
as a whole is bit-rotting and no one attempts to address this. There
are several recent examples of this:
* I recently send out a 100-patches series to improve parameter
parsing and avoid memory leaks. That got shot down. I didn't attempt
to support parameter parsing for module builds.
* There's been a 15-yrs old bug in fbdev's read/write where they
return an incorrect value.
* See the other discussion on this patchset on the state of hitfb.
* The fbdev code I recently cleaned up had bugs in how it uses some
of fbdev's basic building blocks (see the screen_base/screen_buffer
confusion).
* <asm-generic/fb.h> has been in the tree since 2009 and no one
attempted to include it until now.
None of this is a sign of good maintenance.
As I've worked on DRM's fbdev emulation a lot, I try to be a good
kernel citizen and clean up in fbdev as well when I see a problem.> But I'd really like to see most of these drivers being moved into
staging and deleted soon afterwards. Users will complain about those
drivers that are really still required. Those might be worth to spend
effort on.
You don't mention that for most older machines DRM isn't an
acceptable way to go due to it's limitations, e.g. it's low-speed
due to missing 2D-acceleration for older cards and and it's
incapability to change screen resolution at runtime (just to name
two of the bigger limitations here).
You can change resolution at runtime; just not through fbdev ioctls.
There's no technical limitation here. No one found any use for this,
so it's not there.
So, unless we somehow find a good way to move such drivers over to
DRM (with a set of minimal 2D acceleration), they are still
important.
2d acceleration is mostly useful for the framebuffer console.
You can
do that with DRM and drivers have (nouveau). It just didn't make a
meaningful difference in most cases.
Actually, I just did test matroxfb and pm2fb successfully a few
days back, and they worked. For some smaller issues I've prepared
patches, which are on hold due conflicts with your latest
file-move-around- and whitespace-changes which are partly in
drm-misc. And I do have some upcoming additional patches for
console support.