Hi all,
fbdev is (more or less) maintained, but it's a deprecated framework. All new Linux display drivers should be done on DRM.
So let's not add any more new fbdev drivers.
I will continue to maintain the current fbdev drivers, and I don't mind adding some new features to those current drivers, as long as the amount of code required to add the features stays sensible.
I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb, and the question is what to do with those.
xgifb was added in 2010, and is still in staging.
fbtft looks like maybe some kind of framework on top of fbdev, with fbtft specific subdrivers... I didn't look at it in detail, but my gut says "never".
SM750 hardware seems to support multiple outputs, hardware overlays, 2D accelerator... I think it's pointless to write an fbdev driver for such a HW, as it's not possible to use those features with fbdev (without custom API).
So, without spending too much time looking at those drivers, and without speaking to the authors, my initial suggestion is to remove them.
Tomi
Hello,
On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
fbdev is (more or less) maintained, but it's a deprecated framework. All new Linux display drivers should be done on DRM.
So let's not add any more new fbdev drivers.
I will continue to maintain the current fbdev drivers, and I don't mind adding some new features to those current drivers, as long as the amount of code required to add the features stays sensible.
I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb, and the question is what to do with those.
xgifb was added in 2010, and is still in staging.
fbtft looks like maybe some kind of framework on top of fbdev, with fbtft specific subdrivers... I didn't look at it in detail, but my gut says "never".
fbtft mainly drives some very simple I2C-based or SPI-based displays, and DRM is I believe overkill for such displays. Last time I talked with Laurent Pinchart about such drivers, I believe he said that such simple drivers could probably continue to use the fbdev subsystem.
Or are there some plans to make the writing of DRM drivers for very simple/trivial devices a bit simpler?
Thomas
On 2015-09-24 08:46, Thomas Petazzoni wrote:
Hello,
On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
fbdev is (more or less) maintained, but it's a deprecated framework. All new Linux display drivers should be done on DRM.
So let's not add any more new fbdev drivers.
I will continue to maintain the current fbdev drivers, and I don't mind adding some new features to those current drivers, as long as the amount of code required to add the features stays sensible.
I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb, and the question is what to do with those.
xgifb was added in 2010, and is still in staging.
fbtft looks like maybe some kind of framework on top of fbdev, with fbtft specific subdrivers... I didn't look at it in detail, but my gut says "never".
fbtft mainly drives some very simple I2C-based or SPI-based displays, and DRM is I believe overkill for such displays. Last time I talked with Laurent Pinchart about such drivers, I believe he said that such simple drivers could probably continue to use the fbdev subsystem.
I have to agree, using DRM _really_ doesn't make sense for these, the devices in question are (AFAIK) simple I2C or SPI connected frame-buffer chips that are hooked up to equally simple TFT displays. There's no 3d acceleration at all from what I can tell, there's _very_ limited 2d acceleration, and most of the stuff that the DRM framework provides call-backs for would have to be done on the CPU anyway. On top of that, it's targeted at small embedded systems with limited memory, and the DRM framework is by no-means lightweight (TBH, fbdev isn't really either, but it's much more light weight than DRM).
On Thu, Sep 24, 2015 at 11:21 AM, Austin S Hemmelgarn ahferroin7@gmail.com wrote:
On 2015-09-24 08:46, Thomas Petazzoni wrote:
Hello,
On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
fbdev is (more or less) maintained, but it's a deprecated framework. All new Linux display drivers should be done on DRM.
So let's not add any more new fbdev drivers.
I will continue to maintain the current fbdev drivers, and I don't mind adding some new features to those current drivers, as long as the amount of code required to add the features stays sensible.
I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb, and the question is what to do with those.
xgifb was added in 2010, and is still in staging.
fbtft looks like maybe some kind of framework on top of fbdev, with fbtft specific subdrivers... I didn't look at it in detail, but my gut says "never".
fbtft mainly drives some very simple I2C-based or SPI-based displays, and DRM is I believe overkill for such displays. Last time I talked with Laurent Pinchart about such drivers, I believe he said that such simple drivers could probably continue to use the fbdev subsystem.
I have to agree, using DRM _really_ doesn't make sense for these, the devices in question are (AFAIK) simple I2C or SPI connected frame-buffer chips that are hooked up to equally simple TFT displays. There's no 3d acceleration at all from what I can tell, there's _very_ limited 2d acceleration, and most of the stuff that the DRM framework provides call-backs for would have to be done on the CPU anyway.
Just about all of the acceleration stuff is vendor specific so there's really nothing you need to provide. As Daniel noted there are several drm drivers for simple devices that do not support any kind of 2D or 3D acceleration. There are no requirements to provide any sort of acceleration.
Alex
On Thu, Sep 24, 2015 at 11:21:15AM -0400, Austin S Hemmelgarn wrote:
On 2015-09-24 08:46, Thomas Petazzoni wrote:
Hello,
On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
fbdev is (more or less) maintained, but it's a deprecated framework. All new Linux display drivers should be done on DRM.
So let's not add any more new fbdev drivers.
I will continue to maintain the current fbdev drivers, and I don't mind adding some new features to those current drivers, as long as the amount of code required to add the features stays sensible.
I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb, and the question is what to do with those.
xgifb was added in 2010, and is still in staging.
fbtft looks like maybe some kind of framework on top of fbdev, with fbtft specific subdrivers... I didn't look at it in detail, but my gut says "never".
fbtft mainly drives some very simple I2C-based or SPI-based displays, and DRM is I believe overkill for such displays. Last time I talked with Laurent Pinchart about such drivers, I believe he said that such simple drivers could probably continue to use the fbdev subsystem.
I have to agree, using DRM _really_ doesn't make sense for these, the devices in question are (AFAIK) simple I2C or SPI connected frame-buffer chips that are hooked up to equally simple TFT displays. There's no 3d acceleration at all from what I can tell, there's _very_ limited 2d acceleration, and most of the stuff that the DRM framework provides call-backs for would have to be done on the CPU anyway. On top of that, it's targeted at small embedded systems with limited memory, and the DRM framework is by no-means lightweight (TBH, fbdev isn't really either, but it's much more light weight than DRM).
See my other mail, but you can write very simple drm drivers. And if there's really a bloat problem for small systems we can add Kconfig knobs to throw out everything not needed for simple drivers. The only problem really is that everyone with such simple drivers doesn't even consider drm "because I don't have a desktop gpu" which is just silly - drm has become rather flexible. And that's essentially why writing simple drm drivers still has a bit too much boilerplate, since no one yet bothered to add a bit of helper support needed.
Thanks, Daniel
On 2015-09-24 11:59, Daniel Vetter wrote:
On Thu, Sep 24, 2015 at 11:21:15AM -0400, Austin S Hemmelgarn wrote:
On 2015-09-24 08:46, Thomas Petazzoni wrote:
Hello,
On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
fbdev is (more or less) maintained, but it's a deprecated framework. All new Linux display drivers should be done on DRM.
So let's not add any more new fbdev drivers.
I will continue to maintain the current fbdev drivers, and I don't mind adding some new features to those current drivers, as long as the amount of code required to add the features stays sensible.
I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb, and the question is what to do with those.
xgifb was added in 2010, and is still in staging.
fbtft looks like maybe some kind of framework on top of fbdev, with fbtft specific subdrivers... I didn't look at it in detail, but my gut says "never".
fbtft mainly drives some very simple I2C-based or SPI-based displays, and DRM is I believe overkill for such displays. Last time I talked with Laurent Pinchart about such drivers, I believe he said that such simple drivers could probably continue to use the fbdev subsystem.
I have to agree, using DRM _really_ doesn't make sense for these, the devices in question are (AFAIK) simple I2C or SPI connected frame-buffer chips that are hooked up to equally simple TFT displays. There's no 3d acceleration at all from what I can tell, there's _very_ limited 2d acceleration, and most of the stuff that the DRM framework provides call-backs for would have to be done on the CPU anyway. On top of that, it's targeted at small embedded systems with limited memory, and the DRM framework is by no-means lightweight (TBH, fbdev isn't really either, but it's much more light weight than DRM).
See my other mail, but you can write very simple drm drivers. And if there's really a bloat problem for small systems we can add Kconfig knobs to throw out everything not needed for simple drivers. The only problem really is that everyone with such simple drivers doesn't even consider drm "because I don't have a desktop gpu" which is just silly - drm has become rather flexible. And that's essentially why writing simple drm drivers still has a bit too much boilerplate, since no one yet bothered to add a bit of helper support needed.
Rather ironically, I got your other mail right after I sent this one. I hadn't realized most of the points you made there (it's been a long time since I looked at any drm related code (largely because I've had absolutely 0 issues on my systems with it, which is a good thing :))). I do think being able to compile out some of the drm stuff that isn't used on a given system would be nice, and some good helper functions to simplify writing basic drivers would be absolutely wonderful.
As far as not considering it 'because I don't have a desktop GPU' goes, I agree, that is silly, although for some people it may be 'because my chip doesn't do any "rendering"', which brings up the rather complicated discussion of what constitutes a GPU and what 'rendering' means.
On Thursday 24 September 2015 17:59:12 Daniel Vetter wrote:
On Thu, Sep 24, 2015 at 11:21:15AM -0400, Austin S Hemmelgarn wrote:
On 2015-09-24 08:46, Thomas Petazzoni wrote:
Hello,
On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
fbdev is (more or less) maintained, but it's a deprecated framework. All new Linux display drivers should be done on DRM.
So let's not add any more new fbdev drivers.
I will continue to maintain the current fbdev drivers, and I don't mind adding some new features to those current drivers, as long as the amount of code required to add the features stays sensible.
I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb, and the question is what to do with those.
xgifb was added in 2010, and is still in staging.
fbtft looks like maybe some kind of framework on top of fbdev, with fbtft specific subdrivers... I didn't look at it in detail, but my gut says "never".
fbtft mainly drives some very simple I2C-based or SPI-based displays, and DRM is I believe overkill for such displays. Last time I talked with Laurent Pinchart about such drivers, I believe he said that such simple drivers could probably continue to use the fbdev subsystem.
I have to agree, using DRM _really_ doesn't make sense for these, the devices in question are (AFAIK) simple I2C or SPI connected frame-buffer chips that are hooked up to equally simple TFT displays. There's no 3d acceleration at all from what I can tell, there's _very_ limited 2d acceleration, and most of the stuff that the DRM framework provides call-backs for would have to be done on the CPU anyway. On top of that, it's targeted at small embedded systems with limited memory, and the DRM framework is by no-means lightweight (TBH, fbdev isn't really either, but it's much more light weight than DRM).
See my other mail, but you can write very simple drm drivers. And if there's really a bloat problem for small systems we can add Kconfig knobs to throw out everything not needed for simple drivers. The only problem really is that everyone with such simple drivers doesn't even consider drm "because I don't have a desktop gpu" which is just silly - drm has become rather flexible. And that's essentially why writing simple drm drivers still has a bit too much boilerplate, since no one yet bothered to add a bit of helper support needed.
Is there a simple way to convert existing fbdev drivers to DRM? Let's say I want to convert tridentfb to DRM, keeping the 2D acceleration (pan, fillrect, copyarea, imageblit) to be usable by the console (and maybe extend it to X11 using some generic 2D driver?)
On Thu, Sep 24, 2015 at 07:12:27PM +0200, Ondrej Zary wrote:
On Thursday 24 September 2015 17:59:12 Daniel Vetter wrote:
On Thu, Sep 24, 2015 at 11:21:15AM -0400, Austin S Hemmelgarn wrote:
On 2015-09-24 08:46, Thomas Petazzoni wrote:
Hello,
On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
fbdev is (more or less) maintained, but it's a deprecated framework. All new Linux display drivers should be done on DRM.
So let's not add any more new fbdev drivers.
I will continue to maintain the current fbdev drivers, and I don't mind adding some new features to those current drivers, as long as the amount of code required to add the features stays sensible.
I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb, and the question is what to do with those.
xgifb was added in 2010, and is still in staging.
fbtft looks like maybe some kind of framework on top of fbdev, with fbtft specific subdrivers... I didn't look at it in detail, but my gut says "never".
fbtft mainly drives some very simple I2C-based or SPI-based displays, and DRM is I believe overkill for such displays. Last time I talked with Laurent Pinchart about such drivers, I believe he said that such simple drivers could probably continue to use the fbdev subsystem.
I have to agree, using DRM _really_ doesn't make sense for these, the devices in question are (AFAIK) simple I2C or SPI connected frame-buffer chips that are hooked up to equally simple TFT displays. There's no 3d acceleration at all from what I can tell, there's _very_ limited 2d acceleration, and most of the stuff that the DRM framework provides call-backs for would have to be done on the CPU anyway. On top of that, it's targeted at small embedded systems with limited memory, and the DRM framework is by no-means lightweight (TBH, fbdev isn't really either, but it's much more light weight than DRM).
See my other mail, but you can write very simple drm drivers. And if there's really a bloat problem for small systems we can add Kconfig knobs to throw out everything not needed for simple drivers. The only problem really is that everyone with such simple drivers doesn't even consider drm "because I don't have a desktop gpu" which is just silly - drm has become rather flexible. And that's essentially why writing simple drm drivers still has a bit too much boilerplate, since no one yet bothered to add a bit of helper support needed.
Is there a simple way to convert existing fbdev drivers to DRM? Let's say I want to convert tridentfb to DRM, keeping the 2D acceleration (pan, fillrect, copyarea, imageblit) to be usable by the console (and maybe extend it to X11 using some generic 2D driver?)
DRM doesn't do generic 2d accel, it's all driver specific. And consensus for 2d accel (at least in X) is pretty much that if you have a 3d gpu use glamour. If you don't have that then use the cpu. There's a hint for drm userspace whether to use shadowfb for cpu rendering or not.
What you can do though if you want is keep your accel code for the fbdev emulation on top of the drm modesetting driver, there's a few oddball drivers who do that. And panning is of course already supported by the modeset api. -Daniel
On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:
Hello,
On Thu, 24 Sep 2015 15:27:01 +0300, Tomi Valkeinen wrote:
fbdev is (more or less) maintained, but it's a deprecated framework. All new Linux display drivers should be done on DRM.
So let's not add any more new fbdev drivers.
I will continue to maintain the current fbdev drivers, and I don't mind adding some new features to those current drivers, as long as the amount of code required to add the features stays sensible.
I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb, and the question is what to do with those.
xgifb was added in 2010, and is still in staging.
fbtft looks like maybe some kind of framework on top of fbdev, with fbtft specific subdrivers... I didn't look at it in detail, but my gut says "never".
fbtft mainly drives some very simple I2C-based or SPI-based displays, and DRM is I believe overkill for such displays. Last time I talked with Laurent Pinchart about such drivers, I believe he said that such simple drivers could probably continue to use the fbdev subsystem.
Or are there some plans to make the writing of DRM drivers for very simple/trivial devices a bit simpler?
Since years I'm trying to sell someone on implementing support for drm_simple_outputs which would collapse the crtc->encoder->connector chain into 1 entity. Would be trivial to implement and then trivial to write simple drivers on top of that. And besides that drm already has piles of reallly simple drivers with just one output and one framebuffer.
There's no reason not to use drm for gfx drivers at all. -Daniel
Hi Daniel,
On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter daniel@ffwll.ch wrote:
On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:
Or are there some plans to make the writing of DRM drivers for very simple/trivial devices a bit simpler?
Since years I'm trying to sell someone on implementing support for drm_simple_outputs which would collapse the crtc->encoder->connector chain into 1 entity. Would be trivial to implement and then trivial to write simple drivers on top of that. And besides that drm already has piles of reallly simple drivers with just one output and one framebuffer.
There's no reason not to use drm for gfx drivers at all.
Good to hear that!
For the (mailing list) record, can you please provide some explicit pointers to these existing really simple drivers?
Thanks!
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 Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven geert@linux-m68k.org wrote:
Hi Daniel,
On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter daniel@ffwll.ch wrote:
On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:
Or are there some plans to make the writing of DRM drivers for very simple/trivial devices a bit simpler?
Since years I'm trying to sell someone on implementing support for drm_simple_outputs which would collapse the crtc->encoder->connector chain into 1 entity. Would be trivial to implement and then trivial to write simple drivers on top of that. And besides that drm already has piles of reallly simple drivers with just one output and one framebuffer.
There's no reason not to use drm for gfx drivers at all.
Good to hear that!
For the (mailing list) record, can you please provide some explicit pointers to these existing really simple drivers?
See the tilcdc, ast, mgag200, and udl drivers for example.
Alex
Thanks!
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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Alex,
On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher alexdeucher@gmail.com wrote:
On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven geert@linux-m68k.org wrote:
On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter daniel@ffwll.ch wrote:
On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:
Or are there some plans to make the writing of DRM drivers for very simple/trivial devices a bit simpler?
Since years I'm trying to sell someone on implementing support for drm_simple_outputs which would collapse the crtc->encoder->connector chain into 1 entity. Would be trivial to implement and then trivial to write simple drivers on top of that. And besides that drm already has piles of reallly simple drivers with just one output and one framebuffer.
There's no reason not to use drm for gfx drivers at all.
Good to hear that!
For the (mailing list) record, can you please provide some explicit pointers to these existing really simple drivers?
See the tilcdc, ast, mgag200, and udl drivers for example.
Thanks for the list!
The smallest of these (udl) still counts in at ca. 2800 LoC, while there are several fbdev drivers that have less than 200 LoC. Granted, these really small ones support a single fixed video mode only, but you can write a simple fbdev driver with mode setting in less than 1000 LoC.
I'm sure DRM can do better?
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
On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven geert@linux-m68k.org wrote:
Hi Alex,
On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher alexdeucher@gmail.com wrote:
On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven geert@linux-m68k.org wrote:
On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter daniel@ffwll.ch wrote:
On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:
Or are there some plans to make the writing of DRM drivers for very simple/trivial devices a bit simpler?
Since years I'm trying to sell someone on implementing support for drm_simple_outputs which would collapse the crtc->encoder->connector chain into 1 entity. Would be trivial to implement and then trivial to write simple drivers on top of that. And besides that drm already has piles of reallly simple drivers with just one output and one framebuffer.
There's no reason not to use drm for gfx drivers at all.
Good to hear that!
For the (mailing list) record, can you please provide some explicit pointers to these existing really simple drivers?
See the tilcdc, ast, mgag200, and udl drivers for example.
Thanks for the list!
The smallest of these (udl) still counts in at ca. 2800 LoC, while there are several fbdev drivers that have less than 200 LoC. Granted, these really small ones support a single fixed video mode only, but you can write a simple fbdev driver with mode setting in less than 1000 LoC.
I'm sure DRM can do better?
Is counting lines really the level of the discussion to go here?
DRM is a big set of helpers, nothing else. If many trivial, small drivers share common code, developers are more than welcome to contribute them to drm-core and help making drivers less complex.
As Daniel mentioned, the connector+encoder+crtc combination is one of those simplifications that would make sense if more such drivers are added. Furthermore, the not-yet-merged SimpleDRM driver is one example how to implement multiple of those dumb-fb drivers with a shared code-base.
Thanks David
Hi David,
On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann dh.herrmann@gmail.com wrote:
On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven geert@linux-m68k.org wrote:
On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher alexdeucher@gmail.com wrote:
On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven geert@linux-m68k.org wrote:
For the (mailing list) record, can you please provide some explicit pointers to these existing really simple drivers?
See the tilcdc, ast, mgag200, and udl drivers for example.
Thanks for the list!
The smallest of these (udl) still counts in at ca. 2800 LoC, while there are several fbdev drivers that have less than 200 LoC. Granted, these really small ones support a single fixed video mode only, but you can write a simple fbdev driver with mode setting in less than 1000 LoC.
I'm sure DRM can do better?
Is counting lines really the level of the discussion to go here?
LoC is not the most important. But if the smallest DRM driver needs an order of magnitude more LoC than the smallest fbdev driver, I start to wonder.
E.g. if I want to write a new simple driver for my new shiny hardware, it can make a big difference if I have to write (and test/debug) 800 LoC, or 3000 LoC.
DRM is a big set of helpers, nothing else. If many trivial, small drivers share common code, developers are more than welcome to contribute them to drm-core and help making drivers less complex.
Good. But from the figures above, I don't think we're at that point yet that writing a new DRM driver is less/equal amount of work than writing a new fbdev driver, at least for some classes of hardware. So it may be a bit premature to put a moratorium on new fbdev drivers. I may be mistaken, I'm still not sufficiently familiar with the DRM subsystem as I'd like to be.
As Daniel mentioned, the connector+encoder+crtc combination is one of those simplifications that would make sense if more such drivers are added. Furthermore, the not-yet-merged SimpleDRM driver is one example how to implement multiple of those dumb-fb drivers with a shared code-base.
Thanks, looking forward to SimpleDRM!
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 Sat, Sep 26, 2015 at 2:46 PM, Geert Uytterhoeven geert@linux-m68k.org wrote:
Hi David,
On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann dh.herrmann@gmail.com wrote:
On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven geert@linux-m68k.org wrote:
On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher alexdeucher@gmail.com wrote:
On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven geert@linux-m68k.org wrote:
For the (mailing list) record, can you please provide some explicit pointers to these existing really simple drivers?
See the tilcdc, ast, mgag200, and udl drivers for example.
Thanks for the list!
The smallest of these (udl) still counts in at ca. 2800 LoC, while there are several fbdev drivers that have less than 200 LoC. Granted, these really small ones support a single fixed video mode only, but you can write a simple fbdev driver with mode setting in less than 1000 LoC.
I'm sure DRM can do better?
Is counting lines really the level of the discussion to go here?
LoC is not the most important. But if the smallest DRM driver needs an order of magnitude more LoC than the smallest fbdev driver, I start to wonder.
I think most of the drm/kms drivers are bigger due to more features.. iirc original tilcdc was ~2k loc (compared to ~1.6kloc for da8xx-fb), but it already supported multiple modes, page flipping, vblank notification, etc. It has grown since then. Although still probably smaller than downstream da8xx-fb + tda998x hdmi bridge (and re-using the same tda998x bridge code with several other drivers too, compared to downstream solution for the same)..
Probably there is room for more helpers for even more restrictive hw.
BR, -R
E.g. if I want to write a new simple driver for my new shiny hardware, it can make a big difference if I have to write (and test/debug) 800 LoC, or 3000 LoC.
DRM is a big set of helpers, nothing else. If many trivial, small drivers share common code, developers are more than welcome to contribute them to drm-core and help making drivers less complex.
Good. But from the figures above, I don't think we're at that point yet that writing a new DRM driver is less/equal amount of work than writing a new fbdev driver, at least for some classes of hardware. So it may be a bit premature to put a moratorium on new fbdev drivers. I may be mistaken, I'm still not sufficiently familiar with the DRM subsystem as I'd like to be.
As Daniel mentioned, the connector+encoder+crtc combination is one of those simplifications that would make sense if more such drivers are added. Furthermore, the not-yet-merged SimpleDRM driver is one example how to implement multiple of those dumb-fb drivers with a shared code-base.
Thanks, looking forward to SimpleDRM!
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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 27 September 2015 at 06:49, Rob Clark robdclark@gmail.com wrote:
On Sat, Sep 26, 2015 at 2:46 PM, Geert Uytterhoeven geert@linux-m68k.org wrote:
Hi David,
On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann dh.herrmann@gmail.com wrote:
On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven geert@linux-m68k.org wrote:
On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher alexdeucher@gmail.com wrote:
On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven geert@linux-m68k.org wrote:
For the (mailing list) record, can you please provide some explicit pointers to these existing really simple drivers?
See the tilcdc, ast, mgag200, and udl drivers for example.
Thanks for the list!
The smallest of these (udl) still counts in at ca. 2800 LoC, while there are several fbdev drivers that have less than 200 LoC. Granted, these really small ones support a single fixed video mode only, but you can write a simple fbdev driver with mode setting in less than 1000 LoC.
I'm sure DRM can do better?
Is counting lines really the level of the discussion to go here?
LoC is not the most important. But if the smallest DRM driver needs an order of magnitude more LoC than the smallest fbdev driver, I start to wonder.
I think most of the drm/kms drivers are bigger due to more features.. iirc original tilcdc was ~2k loc (compared to ~1.6kloc for da8xx-fb), but it already supported multiple modes, page flipping, vblank notification, etc. It has grown since then. Although still probably smaller than downstream da8xx-fb + tda998x hdmi bridge (and re-using the same tda998x bridge code with several other drivers too, compared to downstream solution for the same)..
Probably there is room for more helpers for even more restrictive hw.
My main worry for having helpers for "simple" hw, is that people start using them to have a minimal 400loc driver, but once they add any feature outside the helper they have to rewrite their driver to avoid the helpers.
Most of the drm driver is boilerplate, we could possibly reduce the boilerplate, but I'm not sure it's worth the effort to save somebody a small bit of trouble at bringup.
loc is a pointless tool for measuring this, a small drm driver will be as simple as a small fbdev driver, and will likely provide more features that people need.
Dave.
Hi all,
On 26 September 2015 at 19:46, Geert Uytterhoeven geert@linux-m68k.org wrote:
Hi David,
On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann dh.herrmann@gmail.com wrote:
On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven geert@linux-m68k.org wrote:
On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher alexdeucher@gmail.com wrote:
On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven geert@linux-m68k.org wrote:
For the (mailing list) record, can you please provide some explicit pointers to these existing really simple drivers?
See the tilcdc, ast, mgag200, and udl drivers for example.
Thanks for the list!
The smallest of these (udl) still counts in at ca. 2800 LoC, while there are several fbdev drivers that have less than 200 LoC. Granted, these really small ones support a single fixed video mode only, but you can write a simple fbdev driver with mode setting in less than 1000 LoC.
I'm sure DRM can do better?
Is counting lines really the level of the discussion to go here?
LoC is not the most important. But if the smallest DRM driver needs an order of magnitude more LoC than the smallest fbdev driver, I start to wonder.
E.g. if I want to write a new simple driver for my new shiny hardware, it can make a big difference if I have to write (and test/debug) 800 LoC, or 3000 LoC.
Ftr, the smallest DRM/KMS driver that I could see is the layerscape (fsl-dcu) one. It is roughly 1.4k LoC which includes ~300 worth of defines, licence headers and build glue. Admittedly not it's not as low as 200-800 LoC, but it's an example that they can get smaller, as helpers in drm core are added. udl has been written quite some time ago and doesn't make use of atomics, etc. the latter of which should make things easier/shorter.
Regards, Emil
Hi,
As Daniel mentioned, the connector+encoder+crtc combination is one of those simplifications that would make sense if more such drivers are added.
Another one is memory management. It's pretty complex because it can handle _way_ more than what simple drivers need, and the result is _alot_ of ttm boilerplate in the drivers.
cheers, Gerd
On Mon, Sep 28, 2015 at 09:39:13AM +0200, Gerd Hoffmann wrote:
Hi,
As Daniel mentioned, the connector+encoder+crtc combination is one of those simplifications that would make sense if more such drivers are added.
Another one is memory management. It's pretty complex because it can handle _way_ more than what simple drivers need, and the result is _alot_ of ttm boilerplate in the drivers.
ttm is pretty impressive overkill for most simplistic drm drivers. If you just need contiguous framebuffers for display then the cma helpers should take care of pretty much all the boilerplate for you. They have ready-made simple gem and dumb framebuffer mmap support, which is all a basic kms driver needs. -Daniel
On Mo, 2015-09-28 at 14:36 +0200, Daniel Vetter wrote:
On Mon, Sep 28, 2015 at 09:39:13AM +0200, Gerd Hoffmann wrote:
Hi,
As Daniel mentioned, the connector+encoder+crtc combination is one of those simplifications that would make sense if more such drivers are added.
Another one is memory management. It's pretty complex because it can handle _way_ more than what simple drivers need, and the result is _alot_ of ttm boilerplate in the drivers.
ttm is pretty impressive overkill for most simplistic drm drivers. If you just need contiguous framebuffers for display then the cma helpers should take care of pretty much all the boilerplate for you. They have ready-made simple gem and dumb framebuffer mmap support, which is all a basic kms driver needs.
Does that work on !arm meanwhile? Last time I checked (when writing bochsdrm, around v3.14) the cma helpers didn't even build on x86 ...
cheers, Gerd
Hi Gerd,
On Tuesday 29 September 2015 10:23:23 Gerd Hoffmann wrote:
On Mo, 2015-09-28 at 14:36 +0200, Daniel Vetter wrote:
On Mon, Sep 28, 2015 at 09:39:13AM +0200, Gerd Hoffmann wrote:
Hi,
As Daniel mentioned, the connector+encoder+crtc combination is one of those simplifications that would make sense if more such drivers are added.
Another one is memory management. It's pretty complex because it can handle _way_ more than what simple drivers need, and the result is _alot_ of ttm boilerplate in the drivers.
ttm is pretty impressive overkill for most simplistic drm drivers. If you just need contiguous framebuffers for display then the cma helpers should take care of pretty much all the boilerplate for you. They have ready-made simple gem and dumb framebuffer mmap support, which is all a basic kms driver needs.
Does that work on !arm meanwhile? Last time I checked (when writing bochsdrm, around v3.14) the cma helpers didn't even build on x86 ...
config DRM_GEM_CMA_HELPER bool depends on DRM && HAVE_DMA_ATTRS help Choose this if you need the GEM CMA helper functions
x86 defines HAVE_DMA_ATTRS.
On Sat, Sep 26, 2015 at 11:01 AM, Geert Uytterhoeven geert@linux-m68k.org wrote:
The smallest of these (udl) still counts in at ca. 2800 LoC,
Note udlfb.c, the original fbdev driver that I helped write and that the udl DRM driver was based on, is ~1800 LoC ... so we're actually talking in the ballpark of 2x (rather than 10x) between fbdev and DRM in this case. That said, the complexity difference is probably higher than the LoC difference. I know I personally have struggled in the shift from understanding fbdev to understanding DRM.
The fact that there's drivers of both types and USB hardware might make udl may be a good driver to use as a base for any additional simplification / helper work. David Airlie and David Herrmann both have this hardware. David Airlie did the port from fbdev to DRM, so he's made it an exemplary driver. And if anyone needs any hardware which works with udlfb and udl, we're happy to send free hardware to any programmers who are willing to contribute in the form of code or testing: http://plugable.com/projects/plugable-open-source-hardware-samples-program
More simplification and documentation would be great. In particular, the optimization for the connector+encoder+crtc combination others have mentioned seems like it would be worthwhile.
Cheers, Bernie
On Mon, Sep 28, 2015 at 01:52:31PM -0700, Bernie Thompson wrote:
On Sat, Sep 26, 2015 at 11:01 AM, Geert Uytterhoeven geert@linux-m68k.org wrote:
The smallest of these (udl) still counts in at ca. 2800 LoC,
Note udlfb.c, the original fbdev driver that I helped write and that the udl DRM driver was based on, is ~1800 LoC ... so we're actually talking in the ballpark of 2x (rather than 10x) between fbdev and DRM in this case. That said, the complexity difference is probably higher than the LoC difference. I know I personally have struggled in the shift from understanding fbdev to understanding DRM.
udl has a bit of room for improvement, we really should push the worker logicy for fbdev emulation into the core drm fbdev helpers using the ->dirtyfb callback. That should rip out quite a few lines.
The other thing to consider is that drm/udl supports PRIME buffer sharing for seamlessly extending your desktop by just plugging in an usb dongle.
The fact that there's drivers of both types and USB hardware might make udl may be a good driver to use as a base for any additional simplification / helper work. David Airlie and David Herrmann both have this hardware. David Airlie did the port from fbdev to DRM, so he's made it an exemplary driver. And if anyone needs any hardware which works with udlfb and udl, we're happy to send free hardware to any programmers who are willing to contribute in the form of code or testing: http://plugable.com/projects/plugable-open-source-hardware-samples-program
For example drivers I think it's better to look at the latest drm driver merged - those are up-to-date wrt best practices. udl has already accumulated a bit of cruft (e.g. still using legacy modeset helpers and not the atomic ones).
More simplification and documentation would be great. In particular, the optimization for the connector+encoder+crtc combination others have mentioned seems like it would be worthwhile.
Atomic helpers already make almost everything optional except for the crtc-level enable/disable callbacks and the per-plane atomic_plane_update (for buffer flips/panning/rotation/...). So a comibined helper would be mostly for cutting down the structure setup/teardown boilerplate. So should be fairly easy to implement even for drm beginners (when using one of the latest drivers as a template for what needs to be done). -Daniel
Hi,
On Thu, Sep 24, 2015 at 03:27:01PM +0300, Tomi Valkeinen wrote:
fbdev is (more or less) maintained, but it's a deprecated framework. All new Linux display drivers should be done on DRM.
So let's not add any more new fbdev drivers.
I will continue to maintain the current fbdev drivers, and I don't mind adding some new features to those current drivers, as long as the amount of code required to add the features stays sensible.
I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb, and the question is what to do with those.
I was still planning to work on xgifb as I need it on some systems for the console.
A.
On Friday 25 September 2015, Aaro Koskinen wrote:
Hi,
On Thu, Sep 24, 2015 at 03:27:01PM +0300, Tomi Valkeinen wrote:
fbdev is (more or less) maintained, but it's a deprecated framework. All new Linux display drivers should be done on DRM.
So let's not add any more new fbdev drivers.
I will continue to maintain the current fbdev drivers, and I don't mind adding some new features to those current drivers, as long as the amount of code required to add the features stays sensible.
I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb, and the question is what to do with those.
I was still planning to work on xgifb as I need it on some systems for the console.
xgifb supports these devices: PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_20 PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_27 PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_40 PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_42
Two of them are already supported by sisfb: PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_20 PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_40
So I think that support for the remaining two (and missing features, if any) should be added to sisfb.
On Thu, Sep 24, 2015 at 03:27:01PM +0300, Tomi Valkeinen wrote:
Hi all,
fbdev is (more or less) maintained, but it's a deprecated framework. All new Linux display drivers should be done on DRM.
<snip>
SM750 hardware seems to support multiple outputs, hardware overlays, 2D accelerator... I think it's pointless to write an fbdev driver for such a HW, as it's not possible to use those features with fbdev (without custom API).
Yes, it supports these and even SM712 which was recently moved out of staging to fbdev area (which is the main reason that this thread started) also supports dual display and 2D acceleration but those features are not yet done in that driver. SM750 will also have its code cleaned in few months so that it will be ready to be moved out of staging. Right now we only have the framebuffer driver and this hardware is being used in many laptops and notebooks. As of now drm driver is not there for both SM712 and SM750. So then what happens after SM750 is ready to be moved out? Will it be accepted in fbdev or it will have to stay in staging untill a drm driver is ready?
BTW, I had a doubt about drm drivers. Is there any library or test suite to test the driver? I am almost halfway in making a KMS driver for SM712 but still don't know how to test it properly. I was thinkig of asking Daniel offlist but since this thread came up so asking here.
regards sudip
On Sat, Sep 26, 2015 at 3:15 AM, Sudip Mukherjee sudipm.mukherjee@gmail.com wrote:
BTW, I had a doubt about drm drivers. Is there any library or test suite to test the driver? I am almost halfway in making a KMS driver for SM712 but still don't know how to test it properly. I was thinkig of asking Daniel offlist but since this thread came up so asking here.
Take a look at the modetest tool, part of libdrm: http://cgit.freedesktop.org/mesa/drm/tree/tests/modetest
It's quite handy and contains command-line access to a lot of the various KMS functionality, changing modes, configuring planes, different formats, etc.
-ilia
Den 24.09.2015 14:27, skrev Tomi Valkeinen:
Hi all,
fbdev is (more or less) maintained, but it's a deprecated framework. All new Linux display drivers should be done on DRM.
So let's not add any more new fbdev drivers.
I will continue to maintain the current fbdev drivers, and I don't mind adding some new features to those current drivers, as long as the amount of code required to add the features stays sensible.
I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb, and the question is what to do with those.
xgifb was added in 2010, and is still in staging.
fbtft looks like maybe some kind of framework on top of fbdev, with fbtft specific subdrivers... I didn't look at it in detail, but my gut says "never".
I have done some work [1] to try and make fbtft look more like the rest of the kernel (doc [2]), but that work will result in an almost complete rewrite of fbtft. When Tomi showed reluctance to move sm712fb out of staging [3], I started to look at DRM to see if I could find my way through the myriad of helpers and objects/structs.
I now have this simplified view of DRM [4]:
struct tinydrm_device { struct drm_device *base; struct drm_plane plane; struct drm_crtc crtc; struct drm_encoder encoder; struct drm_connector connector; struct drm_fbdev_cma *fbdev_cma; bool enabled; u32 width, height; void *dev_private;
int (*enable)(struct tinydrm_device *tdev); int (*disable)(struct tinydrm_device *tdev);
int (*dirty)(struct drm_framebuffer *fb, struct drm_gem_cma_object *cma_obj, unsigned flags, unsigned color, struct drm_clip_rect *clips, unsigned num_clips); /* blank() is missing */ /* maybe some modeset() function to set hw rotation */ };
Currently I'm able to get fbdev framebuffer changes through as dirty() calls. Next step is to hook up some of the rewritten fbtft code to actually get something on the display.
This is the display controller abstraction I use in the rewritten fbtft:
struct lcdctrl { struct lcdreg *lcdreg; u32 width; u32 height; u32 rotation; bool enabled; struct regulator *power_supply; void *driver_private; u64 flags;
int (*poweron)(struct lcdctrl *ctrl); void (*poweroff)(struct lcdctrl *ctrl); int (*update)(struct lcdctrl *ctrl, struct lcdctrl_update *update); int (*rotate)(struct lcdctrl *ctrl, u32 rotation); int (*blank)(struct lcdctrl *ctrl, bool blank); bool (*check)(struct lcdctrl *ctrl, u32 value); };
So what I would like, is to have a simple struct like this to hide the complexity of the graphics subsystem. Leaving the driver with just a few lines of code to setup the controller:
static int ada_mipifb_1480_poweron(struct lcdctrl *ctrl) { lcdreg_reset(reg); lcdreg_writereg(reg, ILI9340_PWCTRL1, 0x23); [...] }
static int ada_mipifb_probe(struct spi_device *spi) { cfg.width = 240; cfg.height = 320; cfg.addr_mode0 = ILI9340_MADCTL_MX; cfg.addr_mode90 = ILI9340_MADCTL_MV | ILI9340_MADCTL_MY | ILI9340_MADCTL_MX; cfg.addr_mode180 = ILI9340_MADCTL_MY; cfg.addr_mode270 = ILI9340_MADCTL_MV; cfg.bgr = true;
reg = devm_lcdreg_spi_init(spi, LCDREG_SPI_4WIRE);
ctrl = devm_mipi_dbi_init(reg, &cfg); ctrl->poweron = ada_mipifb_1480_poweron;
return devm_lcdctrl_register(ctrl); }
For me personally it doesn't matter whether these drivers are drm or fbdev. fbdev has everything these drivers need, but maybe it's not such a good choice for the future.
Noralf.
[1] https://github.com/notro/linux-staging/commits/next [2] https://github.com/notro/linux-staging/blob/next/drivers/staging/fbtft/Docum... [3] https://lkml.org/lkml/2015/9/1/274 [4] https://gist.github.com/notro/59e0c064bc512e85e9b2
Hi all,
On 27 September 2015 at 14:09, Noralf Trønnes noralf@tronnes.org wrote:
Den 24.09.2015 14:27, skrev Tomi Valkeinen:
Hi all,
fbdev is (more or less) maintained, but it's a deprecated framework. All new Linux display drivers should be done on DRM.
So let's not add any more new fbdev drivers.
I will continue to maintain the current fbdev drivers, and I don't mind adding some new features to those current drivers, as long as the amount of code required to add the features stays sensible.
I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb, and the question is what to do with those.
xgifb was added in 2010, and is still in staging.
fbtft looks like maybe some kind of framework on top of fbdev, with fbtft specific subdrivers... I didn't look at it in detail, but my gut says "never".
I have done some work [1] to try and make fbtft look more like the rest of the kernel (doc [2]), but that work will result in an almost complete rewrite of fbtft. From a very quick skim fbtft looks pretty much like drm/panel. We
presently have 30+ 'simple' dsi panels, plus a bunch of spi ones. Have you had a look at these ?
Cheers, Emil
Den 27.09.2015 18:08, skrev Emil Velikov:
Hi all,
On 27 September 2015 at 14:09, Noralf Trønnes noralf@tronnes.org wrote:
Den 24.09.2015 14:27, skrev Tomi Valkeinen:
Hi all,
fbdev is (more or less) maintained, but it's a deprecated framework. All new Linux display drivers should be done on DRM.
So let's not add any more new fbdev drivers.
I will continue to maintain the current fbdev drivers, and I don't mind adding some new features to those current drivers, as long as the amount of code required to add the features stays sensible.
I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb, and the question is what to do with those.
xgifb was added in 2010, and is still in staging.
fbtft looks like maybe some kind of framework on top of fbdev, with fbtft specific subdrivers... I didn't look at it in detail, but my gut says "never".
I have done some work [1] to try and make fbtft look more like the rest of the kernel (doc [2]), but that work will result in an almost complete rewrite of fbtft.
From a very quick skim fbtft looks pretty much like drm/panel. We presently have 30+ 'simple' dsi panels, plus a bunch of spi ones. Have you had a look at these ?
Thanks, that was useful. I can use drm_panel to setup the controller (prepare) and do backlight (enable/disable), but I need a way to send framebuffer changes. I could do this:
struct tinydrm_panel_funcs { int (*update)(struct drm_framebuffer *fb, struct drm_gem_cma_object *cma_obj, unsigned flags, unsigned color, struct drm_clip_rect *clips, unsigned num_clips); };
struct tinydrm_panel { struct drm_panel panel; u32 width; u32 height; void *dev_private;
const struct tinydrm_panel_funcs *funcs; };
On Tue, Sep 29, 2015 at 12:51:38AM +0200, Noralf Trønnes wrote:
Den 27.09.2015 18:08, skrev Emil Velikov:
Hi all,
On 27 September 2015 at 14:09, Noralf Trønnes noralf@tronnes.org wrote:
Den 24.09.2015 14:27, skrev Tomi Valkeinen:
Hi all,
fbdev is (more or less) maintained, but it's a deprecated framework. All new Linux display drivers should be done on DRM.
So let's not add any more new fbdev drivers.
I will continue to maintain the current fbdev drivers, and I don't mind adding some new features to those current drivers, as long as the amount of code required to add the features stays sensible.
I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb, and the question is what to do with those.
xgifb was added in 2010, and is still in staging.
fbtft looks like maybe some kind of framework on top of fbdev, with fbtft specific subdrivers... I didn't look at it in detail, but my gut says "never".
I have done some work [1] to try and make fbtft look more like the rest of the kernel (doc [2]), but that work will result in an almost complete rewrite of fbtft.
From a very quick skim fbtft looks pretty much like drm/panel. We presently have 30+ 'simple' dsi panels, plus a bunch of spi ones. Have you had a look at these ?
Thanks, that was useful. I can use drm_panel to setup the controller (prepare) and do backlight (enable/disable), but I need a way to send framebuffer changes. I could do this:
struct tinydrm_panel_funcs { int (*update)(struct drm_framebuffer *fb, struct drm_gem_cma_object *cma_obj, unsigned flags, unsigned color, struct drm_clip_rect *clips, unsigned num_clips); };
struct tinydrm_panel { struct drm_panel panel; u32 width; u32 height; void *dev_private;
const struct tinydrm_panel_funcs *funcs;};
I'm not sure whether putting the manual-update stuff into drm_panel is a good idea - it's transport/bus (spi, dsi, ...) specific. Not sure how to best solve that. -Daniel
dri-devel@lists.freedesktop.org
-
Aaro Koskinen -
Alex Deucher -
Austin S Hemmelgarn -
Bernie Thompson -
Daniel Vetter -
Dave Airlie -
David Herrmann -
Emil Velikov -
Geert Uytterhoeven -
Gerd Hoffmann -
Ilia Mirkin -
Laurent Pinchart -
Noralf Trønnes -
Ondrej Zary -
Rob Clark -
Sudip Mukherjee -
Thomas Petazzoni -
Tomi Valkeinen