fbtft: 5 years in staging

fbtft: 5 years in staging

[Noralf Trønnes]

Hi,

Since I'm the original author of fbtft I thought I'd highlight a couple
of issues that's probably not well known.

Right after fbtft was added, fbdev was closed for new drivers[1] and
the fbdev maintainer wanted to remove fbtft as a consequence of that
decision, but Greg KH said he'd keep fbtft drivers in staging
"until a matching DRM driver is present in the tree"[2].

There are 2 issues wrt the goal of making a matching DRM driver
(strictly speaking). One is impossible to do (policy), the other is
unlikely to happen:

1. Device Tree 'init' property

All fbtft drivers have controller setup code that matches one
particular display panel. From the start of fbtft it was possible to
override this using platform data. Later when Device Tree support was
added, an 'init=' property to do the same was added.

Example:
	init = <0x10000e5 0x78F0
		0x1000001 0x0100
		0x2000032
		0x1000007 0x0133>;

This translates to:
	register_write(0x00e5, 0x78F0);
	register_write(0x0001, 0x0100);
	mdelay(32);
	register_write(0x0007, 0x0133);

AFAIU setting register values from DT is a no-go, so this functionality
can't be replicated in a DRM driver. Many displays are made to work
using this mechanism, in particular ili9341 based ones.

2. Parallel bus interface

All fbtft drivers support both a SPI and a parallel bus interface
through the fbtft helper module. Many (not all) controllers support more
than one interface. The parallel bus support was added to fbtft in its
early days when not many SPI displays were available (nowadays there's
lots to choose from). fbtft uses bitbanging to drive the parallel
interface so it's really slow, even more slow than SPI and SPI with DMA
beats it thoroughly. I know there are people that use the paralell bus
support, but I don't see much point in it unless we get a parallel bus
subsystem that can use the dedicated hw on certain SoC's (Beaglebone,
Pi). And those SOC's most likely have a parallel video/RGB bus as well,
which IMO is a much better option for a panel.


The following drivers have DRM counterparts that have the same panel
setup code:

- fb_hx8357d.c: drivers/gpu/drm/tiny/hx8357d.c
- fb_ili9341.c: drivers/gpu/drm/tiny/mi0283qt.c
- fb_st7735r.c: drivers/gpu/drm/tiny/st7735r.c
- fb_ili9486.c: Patches are posted on dri-devel[3]

But they don't support all panels based on that controller and they
don't have parallel bus support.

There is actually also another obstacle for conversion and that is, some
of the displays (for which there is builtin driver support) might be
impossible to source except as second hand. And it's not always obvious
which panel is supported by a certain driver.
At least the displays supported by these drivers are listed as
discontinued on the fbtft wiki[4]:
- fb_hx8340bn.c
- fb_hx8347d.c
- fb_ili9320

This one never made it from a prototype to an actual product, because
it was too slow:
- fb_watterott.c

I have no plans to convert fbtft drivers myself, but I figured a 5 year
anniversary was a good excuse for a status update.

Noralf.

[1] https://lkml.org/lkml/2015/9/24/253
[2] https://lkml.org/lkml/2016/11/23/146
[3] https://patchwork.freedesktop.org/series/72645/
[4] https://github.com/notro/fbtft/wiki/LCD-Modules#discontinued-products
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

fbtft: 5 years in staging

[Noralf Trønnes]

Hi,

Since I'm the original author of fbtft I thought I'd highlight a couple
of issues that's probably not well known.

Right after fbtft was added, fbdev was closed for new drivers[1] and
the fbdev maintainer wanted to remove fbtft as a consequence of that
decision, but Greg KH said he'd keep fbtft drivers in staging
"until a matching DRM driver is present in the tree"[2].

There are 2 issues wrt the goal of making a matching DRM driver
(strictly speaking). One is impossible to do (policy), the other is
unlikely to happen:

1. Device Tree 'init' property

All fbtft drivers have controller setup code that matches one
particular display panel. From the start of fbtft it was possible to
override this using platform data. Later when Device Tree support was
added, an 'init=' property to do the same was added.

Example:
	init = <0x10000e5 0x78F0
		0x1000001 0x0100
		0x2000032
		0x1000007 0x0133>;

This translates to:
	register_write(0x00e5, 0x78F0);
	register_write(0x0001, 0x0100);
	mdelay(32);
	register_write(0x0007, 0x0133);

AFAIU setting register values from DT is a no-go, so this functionality
can't be replicated in a DRM driver. Many displays are made to work
using this mechanism, in particular ili9341 based ones.

2. Parallel bus interface

All fbtft drivers support both a SPI and a parallel bus interface
through the fbtft helper module. Many (not all) controllers support more
than one interface. The parallel bus support was added to fbtft in its
early days when not many SPI displays were available (nowadays there's
lots to choose from). fbtft uses bitbanging to drive the parallel
interface so it's really slow, even more slow than SPI and SPI with DMA
beats it thoroughly. I know there are people that use the paralell bus
support, but I don't see much point in it unless we get a parallel bus
subsystem that can use the dedicated hw on certain SoC's (Beaglebone,
Pi). And those SOC's most likely have a parallel video/RGB bus as well,
which IMO is a much better option for a panel.


The following drivers have DRM counterparts that have the same panel
setup code:

- fb_hx8357d.c: drivers/gpu/drm/tiny/hx8357d.c
- fb_ili9341.c: drivers/gpu/drm/tiny/mi0283qt.c
- fb_st7735r.c: drivers/gpu/drm/tiny/st7735r.c
- fb_ili9486.c: Patches are posted on dri-devel[3]

But they don't support all panels based on that controller and they
don't have parallel bus support.

There is actually also another obstacle for conversion and that is, some
of the displays (for which there is builtin driver support) might be
impossible to source except as second hand. And it's not always obvious
which panel is supported by a certain driver.
At least the displays supported by these drivers are listed as
discontinued on the fbtft wiki[4]:
- fb_hx8340bn.c
- fb_hx8347d.c
- fb_ili9320

This one never made it from a prototype to an actual product, because
it was too slow:
- fb_watterott.c

I have no plans to convert fbtft drivers myself, but I figured a 5 year
anniversary was a good excuse for a status update.

Noralf.

[1] https://lkml.org/lkml/2015/9/24/253
[2] https://lkml.org/lkml/2016/11/23/146
[3] https://patchwork.freedesktop.org/series/72645/
[4] https://github.com/notro/fbtft/wiki/LCD-Modules#discontinued-products
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: fbtft: 5 years in staging

[Noralf Trønnes]

Den 02.02.2020 16.41, skrev Noralf Trønnes:
> Hi,
> 
> Since I'm the original author of fbtft I thought I'd highlight a couple
> of issues that's probably not well known.
> 
> Right after fbtft was added, fbdev was closed for new drivers[1] and
> the fbdev maintainer wanted to remove fbtft as a consequence of that
> decision, but Greg KH said he'd keep fbtft drivers in staging
> "until a matching DRM driver is present in the tree"[2].
> 
> There are 2 issues wrt the goal of making a matching DRM driver
> (strictly speaking). One is impossible to do (policy), the other is
> unlikely to happen:
> 
> 1. Device Tree 'init' property
> 
> All fbtft drivers have controller setup code that matches one
> particular display panel. From the start of fbtft it was possible to
> override this using platform data. Later when Device Tree support was
> added, an 'init=' property to do the same was added.
> 
> Example:
> 	init = <0x10000e5 0x78F0
> 		0x1000001 0x0100
> 		0x2000032
> 		0x1000007 0x0133>;
> 
> This translates to:
> 	register_write(0x00e5, 0x78F0);
> 	register_write(0x0001, 0x0100);
> 	mdelay(32);
> 	register_write(0x0007, 0x0133);
> 
> AFAIU setting register values from DT is a no-go, so this functionality
> can't be replicated in a DRM driver. Many displays are made to work
> using this mechanism, in particular ili9341 based ones.
> 
> 2. Parallel bus interface
> 
> All fbtft drivers support both a SPI and a parallel bus interface
> through the fbtft helper module. Many (not all) controllers support more
> than one interface. The parallel bus support was added to fbtft in its
> early days when not many SPI displays were available (nowadays there's
> lots to choose from). fbtft uses bitbanging to drive the parallel
> interface so it's really slow, even more slow than SPI and SPI with DMA
> beats it thoroughly. I know there are people that use the paralell bus
> support, but I don't see much point in it unless we get a parallel bus
> subsystem that can use the dedicated hw on certain SoC's (Beaglebone,
> Pi). And those SOC's most likely have a parallel video/RGB bus as well,
> which IMO is a much better option for a panel.
> 
> 
> The following drivers have DRM counterparts that have the same panel
> setup code:
> 
> - fb_hx8357d.c: drivers/gpu/drm/tiny/hx8357d.c
> - fb_ili9341.c: drivers/gpu/drm/tiny/mi0283qt.c
> - fb_st7735r.c: drivers/gpu/drm/tiny/st7735r.c
> - fb_ili9486.c: Patches are posted on dri-devel[3]
> 
> But they don't support all panels based on that controller and they
> don't have parallel bus support.
> 
> There is actually also another obstacle for conversion and that is, some
> of the displays (for which there is builtin driver support) might be
> impossible to source except as second hand. And it's not always obvious
> which panel is supported by a certain driver.
> At least the displays supported by these drivers are listed as
> discontinued on the fbtft wiki[4]:
> - fb_hx8340bn.c
> - fb_hx8347d.c
> - fb_ili9320
> 
> This one never made it from a prototype to an actual product, because
> it was too slow:
> - fb_watterott.c
> 
> I have no plans to convert fbtft drivers myself, but I figured a 5 year
> anniversary was a good excuse for a status update.

Some info for anyone wanting to convert fbtft drivers:

The following drivers are MIPI DBI compatible (like the ones already
converted) which means they have the same protocol and share certain
commands. They are very easy to port over for anyone with access to
such a display.

- fb_hx8340bn.c
- fb_hx8353d.c
- fb_ili9340.c
- fb_ili9481.c
- fb_s6d02a1.c
- fb_st7789v.c
- fb_tinylcd.c (probably has an ili9486 chip)
- fb_ili9163.c

(library: drivers/gpu/drm/drm_mipi_dbi.c)

There is also an out-of-tree ili9325 driver that supports the protocol
used by fb_ili9320 and fb_ili9325, but it doesn't support their panels
(at least the register values differ):
https://github.com/notro/tinydrm/blob/master/ili9325.c

> 
> Noralf.
> 
> [1] https://lkml.org/lkml/2015/9/24/253
> [2] https://lkml.org/lkml/2016/11/23/146
> [3] https://patchwork.freedesktop.org/series/72645/
> [4] https://github.com/notro/fbtft/wiki/LCD-Modules#discontinued-products
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: fbtft: 5 years in staging

[Noralf Trønnes]

Den 02.02.2020 16.41, skrev Noralf Trønnes:
> Hi,
> 
> Since I'm the original author of fbtft I thought I'd highlight a couple
> of issues that's probably not well known.
> 
> Right after fbtft was added, fbdev was closed for new drivers[1] and
> the fbdev maintainer wanted to remove fbtft as a consequence of that
> decision, but Greg KH said he'd keep fbtft drivers in staging
> "until a matching DRM driver is present in the tree"[2].
> 
> There are 2 issues wrt the goal of making a matching DRM driver
> (strictly speaking). One is impossible to do (policy), the other is
> unlikely to happen:
> 
> 1. Device Tree 'init' property
> 
> All fbtft drivers have controller setup code that matches one
> particular display panel. From the start of fbtft it was possible to
> override this using platform data. Later when Device Tree support was
> added, an 'init=' property to do the same was added.
> 
> Example:
> 	init = <0x10000e5 0x78F0
> 		0x1000001 0x0100
> 		0x2000032
> 		0x1000007 0x0133>;
> 
> This translates to:
> 	register_write(0x00e5, 0x78F0);
> 	register_write(0x0001, 0x0100);
> 	mdelay(32);
> 	register_write(0x0007, 0x0133);
> 
> AFAIU setting register values from DT is a no-go, so this functionality
> can't be replicated in a DRM driver. Many displays are made to work
> using this mechanism, in particular ili9341 based ones.
> 
> 2. Parallel bus interface
> 
> All fbtft drivers support both a SPI and a parallel bus interface
> through the fbtft helper module. Many (not all) controllers support more
> than one interface. The parallel bus support was added to fbtft in its
> early days when not many SPI displays were available (nowadays there's
> lots to choose from). fbtft uses bitbanging to drive the parallel
> interface so it's really slow, even more slow than SPI and SPI with DMA
> beats it thoroughly. I know there are people that use the paralell bus
> support, but I don't see much point in it unless we get a parallel bus
> subsystem that can use the dedicated hw on certain SoC's (Beaglebone,
> Pi). And those SOC's most likely have a parallel video/RGB bus as well,
> which IMO is a much better option for a panel.
> 
> 
> The following drivers have DRM counterparts that have the same panel
> setup code:
> 
> - fb_hx8357d.c: drivers/gpu/drm/tiny/hx8357d.c
> - fb_ili9341.c: drivers/gpu/drm/tiny/mi0283qt.c
> - fb_st7735r.c: drivers/gpu/drm/tiny/st7735r.c
> - fb_ili9486.c: Patches are posted on dri-devel[3]
> 
> But they don't support all panels based on that controller and they
> don't have parallel bus support.
> 
> There is actually also another obstacle for conversion and that is, some
> of the displays (for which there is builtin driver support) might be
> impossible to source except as second hand. And it's not always obvious
> which panel is supported by a certain driver.
> At least the displays supported by these drivers are listed as
> discontinued on the fbtft wiki[4]:
> - fb_hx8340bn.c
> - fb_hx8347d.c
> - fb_ili9320
> 
> This one never made it from a prototype to an actual product, because
> it was too slow:
> - fb_watterott.c
> 
> I have no plans to convert fbtft drivers myself, but I figured a 5 year
> anniversary was a good excuse for a status update.

Some info for anyone wanting to convert fbtft drivers:

The following drivers are MIPI DBI compatible (like the ones already
converted) which means they have the same protocol and share certain
commands. They are very easy to port over for anyone with access to
such a display.

- fb_hx8340bn.c
- fb_hx8353d.c
- fb_ili9340.c
- fb_ili9481.c
- fb_s6d02a1.c
- fb_st7789v.c
- fb_tinylcd.c (probably has an ili9486 chip)
- fb_ili9163.c

(library: drivers/gpu/drm/drm_mipi_dbi.c)

There is also an out-of-tree ili9325 driver that supports the protocol
used by fb_ili9320 and fb_ili9325, but it doesn't support their panels
(at least the register values differ):
https://github.com/notro/tinydrm/blob/master/ili9325.c

> 
> Noralf.
> 
> [1] https://lkml.org/lkml/2015/9/24/253
> [2] https://lkml.org/lkml/2016/11/23/146
> [3] https://patchwork.freedesktop.org/series/72645/
> [4] https://github.com/notro/fbtft/wiki/LCD-Modules#discontinued-products
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: fbtft: 5 years in staging

[Sam Ravnborg]

Hi Noralf

On Sun, Feb 02, 2020 at 04:41:54PM +0100, Noralf Trønnes wrote:
> Hi,
> 
> Since I'm the original author of fbtft I thought I'd highlight a couple
> of issues that's probably not well known.
> 
> Right after fbtft was added, fbdev was closed for new drivers[1] and
> the fbdev maintainer wanted to remove fbtft as a consequence of that
> decision, but Greg KH said he'd keep fbtft drivers in staging
> "until a matching DRM driver is present in the tree"[2].
> 
> There are 2 issues wrt the goal of making a matching DRM driver
> (strictly speaking). One is impossible to do (policy), the other is
> unlikely to happen:
> 
> 1. Device Tree 'init' property
> 
> All fbtft drivers have controller setup code that matches one
> particular display panel. From the start of fbtft it was possible to
> override this using platform data. Later when Device Tree support was
> added, an 'init=' property to do the same was added.
> 
> Example:
> 	init = <0x10000e5 0x78F0
> 		0x1000001 0x0100
> 		0x2000032
> 		0x1000007 0x0133>;
> 
> This translates to:
> 	register_write(0x00e5, 0x78F0);
> 	register_write(0x0001, 0x0100);
> 	mdelay(32);
> 	register_write(0x0007, 0x0133);
> 
> AFAIU setting register values from DT is a no-go, so this functionality
> can't be replicated in a DRM driver. Many displays are made to work
> using this mechanism, in particular ili9341 based ones.
> 
> 2. Parallel bus interface
> 
> All fbtft drivers support both a SPI and a parallel bus interface
> through the fbtft helper module. Many (not all) controllers support more
> than one interface. The parallel bus support was added to fbtft in its
> early days when not many SPI displays were available (nowadays there's
> lots to choose from). fbtft uses bitbanging to drive the parallel
> interface so it's really slow, even more slow than SPI and SPI with DMA
> beats it thoroughly. I know there are people that use the paralell bus
> support, but I don't see much point in it unless we get a parallel bus
> subsystem that can use the dedicated hw on certain SoC's (Beaglebone,
> Pi). And those SOC's most likely have a parallel video/RGB bus as well,
> which IMO is a much better option for a panel.
> 
> 
> The following drivers have DRM counterparts that have the same panel
> setup code:
> 
> - fb_hx8357d.c: drivers/gpu/drm/tiny/hx8357d.c
> - fb_ili9341.c: drivers/gpu/drm/tiny/mi0283qt.c
> - fb_st7735r.c: drivers/gpu/drm/tiny/st7735r.c
> - fb_ili9486.c: Patches are posted on dri-devel[3]
> 
> But they don't support all panels based on that controller and they
> don't have parallel bus support.
> 
> There is actually also another obstacle for conversion and that is, some
> of the displays (for which there is builtin driver support) might be
> impossible to source except as second hand. And it's not always obvious
> which panel is supported by a certain driver.
> At least the displays supported by these drivers are listed as
> discontinued on the fbtft wiki[4]:
> - fb_hx8340bn.c
> - fb_hx8347d.c
> - fb_ili9320
> 
> This one never made it from a prototype to an actual product, because
> it was too slow:
> - fb_watterott.c
> 
> I have no plans to convert fbtft drivers myself, but I figured a 5 year
> anniversary was a good excuse for a status update.

Thanks for the history lesson and the status update, a very informative
and interesting read.

Thanks for all your work in this area!

	Sam

> 
> Noralf.
> 
> [1] https://lkml.org/lkml/2015/9/24/253
> [2] https://lkml.org/lkml/2016/11/23/146
> [3] https://patchwork.freedesktop.org/series/72645/
> [4] https://github.com/notro/fbtft/wiki/LCD-Modules#discontinued-products
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: fbtft: 5 years in staging

[Sam Ravnborg]

Hi Noralf

On Sun, Feb 02, 2020 at 04:41:54PM +0100, Noralf Trønnes wrote:
> Hi,
> 
> Since I'm the original author of fbtft I thought I'd highlight a couple
> of issues that's probably not well known.
> 
> Right after fbtft was added, fbdev was closed for new drivers[1] and
> the fbdev maintainer wanted to remove fbtft as a consequence of that
> decision, but Greg KH said he'd keep fbtft drivers in staging
> "until a matching DRM driver is present in the tree"[2].
> 
> There are 2 issues wrt the goal of making a matching DRM driver
> (strictly speaking). One is impossible to do (policy), the other is
> unlikely to happen:
> 
> 1. Device Tree 'init' property
> 
> All fbtft drivers have controller setup code that matches one
> particular display panel. From the start of fbtft it was possible to
> override this using platform data. Later when Device Tree support was
> added, an 'init=' property to do the same was added.
> 
> Example:
> 	init = <0x10000e5 0x78F0
> 		0x1000001 0x0100
> 		0x2000032
> 		0x1000007 0x0133>;
> 
> This translates to:
> 	register_write(0x00e5, 0x78F0);
> 	register_write(0x0001, 0x0100);
> 	mdelay(32);
> 	register_write(0x0007, 0x0133);
> 
> AFAIU setting register values from DT is a no-go, so this functionality
> can't be replicated in a DRM driver. Many displays are made to work
> using this mechanism, in particular ili9341 based ones.
> 
> 2. Parallel bus interface
> 
> All fbtft drivers support both a SPI and a parallel bus interface
> through the fbtft helper module. Many (not all) controllers support more
> than one interface. The parallel bus support was added to fbtft in its
> early days when not many SPI displays were available (nowadays there's
> lots to choose from). fbtft uses bitbanging to drive the parallel
> interface so it's really slow, even more slow than SPI and SPI with DMA
> beats it thoroughly. I know there are people that use the paralell bus
> support, but I don't see much point in it unless we get a parallel bus
> subsystem that can use the dedicated hw on certain SoC's (Beaglebone,
> Pi). And those SOC's most likely have a parallel video/RGB bus as well,
> which IMO is a much better option for a panel.
> 
> 
> The following drivers have DRM counterparts that have the same panel
> setup code:
> 
> - fb_hx8357d.c: drivers/gpu/drm/tiny/hx8357d.c
> - fb_ili9341.c: drivers/gpu/drm/tiny/mi0283qt.c
> - fb_st7735r.c: drivers/gpu/drm/tiny/st7735r.c
> - fb_ili9486.c: Patches are posted on dri-devel[3]
> 
> But they don't support all panels based on that controller and they
> don't have parallel bus support.
> 
> There is actually also another obstacle for conversion and that is, some
> of the displays (for which there is builtin driver support) might be
> impossible to source except as second hand. And it's not always obvious
> which panel is supported by a certain driver.
> At least the displays supported by these drivers are listed as
> discontinued on the fbtft wiki[4]:
> - fb_hx8340bn.c
> - fb_hx8347d.c
> - fb_ili9320
> 
> This one never made it from a prototype to an actual product, because
> it was too slow:
> - fb_watterott.c
> 
> I have no plans to convert fbtft drivers myself, but I figured a 5 year
> anniversary was a good excuse for a status update.

Thanks for the history lesson and the status update, a very informative
and interesting read.

Thanks for all your work in this area!

	Sam

> 
> Noralf.
> 
> [1] https://lkml.org/lkml/2015/9/24/253
> [2] https://lkml.org/lkml/2016/11/23/146
> [3] https://patchwork.freedesktop.org/series/72645/
> [4] https://github.com/notro/fbtft/wiki/LCD-Modules#discontinued-products
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: fbtft: 5 years in staging

[Greg Kroah-Hartman]

On Sun, Feb 02, 2020 at 04:41:54PM +0100, Noralf Trønnes wrote:
> Hi,
> 
> Since I'm the original author of fbtft I thought I'd highlight a couple
> of issues that's probably not well known.
> 
> Right after fbtft was added, fbdev was closed for new drivers[1] and
> the fbdev maintainer wanted to remove fbtft as a consequence of that
> decision, but Greg KH said he'd keep fbtft drivers in staging
> "until a matching DRM driver is present in the tree"[2].

<snip>

Thanks for the great summary, much appreciated.

greg k-h
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: fbtft: 5 years in staging

[Greg Kroah-Hartman]

On Sun, Feb 02, 2020 at 04:41:54PM +0100, Noralf Trønnes wrote:
> Hi,
> 
> Since I'm the original author of fbtft I thought I'd highlight a couple
> of issues that's probably not well known.
> 
> Right after fbtft was added, fbdev was closed for new drivers[1] and
> the fbdev maintainer wanted to remove fbtft as a consequence of that
> decision, but Greg KH said he'd keep fbtft drivers in staging
> "until a matching DRM driver is present in the tree"[2].

<snip>

Thanks for the great summary, much appreciated.

greg k-h
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel