On 23/11/16 19:26, Noralf Trønnes wrote:

Den 23.11.2016 09:03, skrev Tomi Valkeinen:

...

Since the fbdev framework is in maintenance mode and all new display drivers should be made with the DRM framework, remove fbtft from staging.

Signed-off-by: Tomi Valkeinen tomi.valkeinen@ti.com

FYI: I'm working on a drm version of fbtft: https://github.com/notro/tinydrm I have just picked it up after a 4 month break.

It is ready for a new review, except that I want to test how it would perform as a drm userspace driver first (for spi that would mean adding dma-buf support to spidev). If this performs well, then all the fbtft drivers could move to userspace. If it doesn't, then at least (very slow) i2c and e-ink displays could be userspace drivers.

Alright, sounds good to me.

So let's keep the staging fbdev drivers there until we have replacements.

Tomi

Hi Daniel,

On Wed, Nov 23, 2016 at 9:19 AM, Daniel Vetter daniel@ffwll.ch wrote:

On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote:

...

Since the fbdev framework is in maintenance mode and all new display drivers should be made with the DRM framework, remove the fbdev drivers from staging.

Note: the patches are created with git format-patch -D, so they can't be applied. Only for review.

+1 from my side. Now that we have the simple pipe helpers in drm-kms, and a few drivers starting to use them, there's really no reasons left anymore to have fbdev drivers.

I haven't been following this that closely, so can you please point me to a sample DRM driver using this simple pipe helper?

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 Wed, Nov 23, 2016 at 11:12:32AM +0200, Tomi Valkeinen wrote:

On 23/11/16 10:52, Greg Kroah-Hartman wrote:

...

On Wed, Nov 23, 2016 at 10:03:10AM +0200, Tomi Valkeinen wrote:

...

Hi,

Since the fbdev framework is in maintenance mode and all new display drivers should be made with the DRM framework, remove the fbdev drivers from staging.

Note: the patches are created with git format-patch -D, so they can't be applied. Only for review.

I only want to remove these drivers if we have the same functionality in mainline for their hardware. If not, that's a bit rude to those who actually use them today, don't you think?

What does it mean for a driver to be in staging? I thought it's basically the same as the driver being out-of-tree, with the difference that the code is in a central git repository for easier co-operation.

Yes, but it also allows people to use their hardware, for drivers that are not "quite ready".

If that's what staging means, then I would reject the staging fbdev drivers the same way as I'd reject new fbdev drivers sent as patches to the list.

Rejecting valid drivers for hardware that people have today is not a nice thing. If you want to just move them into staging so that people can get their hardware working while people port to the new apis, I will be glad to take them.

Or do you mean that we should keep the drivers in staging until there's a matching DRM driver, but drop any plans to move the drivers from staging to drivers/video/? If so, I'm fine with that. This is an RFC, mostly to raise some discussion and push people to actually write those DRM drivers =).

I do not want to move these to drivers/video/ and they should just stay where they are until a matching DRM driver is present in the tree.

thanks,

greg k-h

On Wed, Nov 23, 2016 at 12:05 PM, Thomas Petazzoni thomas.petazzoni@free-electrons.com wrote:

On Wed, 23 Nov 2016 11:12:32 +0200, Tomi Valkeinen wrote:

...

Or do you mean that we should keep the drivers in staging until there's a matching DRM driver, but drop any plans to move the drivers from staging to drivers/video/? If so, I'm fine with that. This is an RFC, mostly to raise some discussion and push people to actually write those DRM drivers =).

The very reason why I submitted those drivers for staging is because lots and lots of people were using out of tree kernel modules for these drivers, which was really a pain.

If you now remove those drivers from staging, then those folks will be back in the situation they originally were, using annoying out of tree modules.

I'm all for removing fbtft drivers progressively as a matching DRM-based driver is available for the same hardware. However, if there is no DRM-based support for a given piece of hardware supported by fbtft, I'd prefer if we kept the fbtft driver for this hardware.

Too many people are playing with big things, I vote +1 to *leave* fbtft for people who prefer small on big.

On Thu, 2016-12-08 at 10:01 +0200, Tomi Valkeinen wrote:

...

DRM drivers don't strike me as suitable for small/slow cores with dumb framebuffers or simple 2D only accel, such as the one found in the ASpeed BMCs.

Then the DRM framework should be improved to be suitable.

Dave ? :-)

...

With drmfb you basically have to shadow everything into memory & copy over everything, and locks you out of simple 2D accel. For a simple text console the result is orders of magnitude slower and memory hungry than a simple fbdev.

I don't think that's true. You can have a single fbdev buffer and blit there all you want, afaik.

Well, I had that argument with Dave Airlie which I CCed. The "dumb" ones like bochsdrmfb, cirrusdrmfb, astdrmfb ... all use shadowing, meaning they use a lot more memory and cannot do any 2D acceleration for fbcon.

From memory, David claimed you cannot directly work on the fb with a "proper"

DRM driver. Maybe I misunderstood but then the DRM shines by its complete absence of useful documentation mixed with bazillion layers of APIs and helpers so it's pretty hard to get ones head around it without wasting very large amounts of time which I don't have at the moment.

...

Not everything has a powerful 3D GPU.

We don't use GPU on OMAPs (except for 3D).

The CPU in an OMAP is order of magnitude faster than what I have in an Aspeed BMC though.

Ben.

On Fri, Dec 09, 2016 at 08:43:13AM +1100, Benjamin Herrenschmidt wrote:

On Fri, 2016-12-09 at 08:23 +1100, Benjamin Herrenschmidt wrote:

...

...

From memory, David claimed you cannot directly work on the fb with a "proper"

DRM driver. Maybe I misunderstood but then the DRM shines by its complete absence of useful documentation

That sentence should have been in the past, it does look like documentation has been landing in the tree this year ! yay ! I'll go off read it.

We've been building up that documentation for years now, not sure where exactly you've looked in the past ;-)

And to make sure you're looking at the right stuff: Please run

$ make DOCBOOKS="" htmldocs

and then look at Documentation/output/gpu. Otherwise all the kerneldoc stuff isn't pulled in, and a lot of the overview sections (not just abi/struct docs) are in there.

And if something looks fishy or doesn't make sense, please raise it here or on #dri-devel on freenode so that we can improve the docs. -Daniel

On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:

On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:

...

Hi,

Since the fbdev framework is in maintenance mode and all new display drivers should be made with the DRM framework, remove the fbdev drivers from staging.

Note: the patches are created with git format-patch -D, so they can't be applied. Only for review.

I missed the discussion where this decision was made, I admit I am unimpressed by it.

DRM drivers don't strike me as suitable for small/slow cores with dumb framebuffers or simple 2D only accel, such as the one found in the ASpeed BMCs.

We have a helper for simple drivers now, if you take into account the massive helper libraries for everything that comes along with drm I expect if even dumb panels behind slow spi buses drm is now the more suitable subsytem.

With drmfb you basically have to shadow everything into memory & copy over everything, and locks you out of simple 2D accel. For a simple text console the result is orders of magnitude slower and memory hungry than a simple fbdev.

Not true, we have full fbdev emulation, and drivers can implement the 2d accel in there. And a bunch of them do. It's just that most teams decided that this is pointless waste of their time.j

At least that was the case last I looked at the DRM stuff with Dave, maybe things have changed...

Not everything has a powerful 3D GPU.

That's correct, and drm can cope. And compared to fbdev there's a very active community who improves&refactors it every kernel release to make it even better. Since about 2 years (when atomic landed) we merge new drivers at a rate of 2-3 per kernel release, and those new drivers get ever simpler and smaller thanks to all this work. -Daniel

On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote:

On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter daniel@ffwll.ch wrote:

...

On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:

...

On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:

...

Since the fbdev framework is in maintenance mode and all new display drivers should be made with the DRM framework, remove the fbdev drivers from staging.

Note: the patches are created with git format-patch -D, so they can't be applied. Only for review.

I missed the discussion where this decision was made, I admit I am unimpressed by it.

DRM drivers don't strike me as suitable for small/slow cores with dumb framebuffers or simple 2D only accel, such as the one found in the ASpeed BMCs.

We have a helper for simple drivers now, if you take into account the massive helper libraries for everything that comes along with drm I expect if even dumb panels behind slow spi buses drm is now the more suitable subsytem.

This has been going on your years:

1. Fbdev is obsolete, everybody should use DRM instead!
2. Can you please point me to a small sample driver for a dumb frame buffer?
3. Several are being written, but none of them is upstream yet.
4. Goto 1.

Wut. We have like 20+ small atomic drivers nowdays.

...

...

With drmfb you basically have to shadow everything into memory & copy over everything, and locks you out of simple 2D accel. For a simple text console the result is orders of magnitude slower and memory hungry than a simple fbdev.

Not true, we have full fbdev emulation, and drivers can implement the 2d accel in there. And a bunch of them do. It's just that most teams decided that this is pointless waste of their time.j

...

At least that was the case last I looked at the DRM stuff with Dave, maybe things have changed...

Not everything has a powerful 3D GPU.

That's correct, and drm can cope. And compared to fbdev there's a very active community who improves&refactors it every kernel release to make it even better. Since about 2 years (when atomic landed) we merge new drivers at a rate of 2-3 per kernel release, and those new drivers get ever simpler and smaller thanks to all this work.

You mean the kind of refactoring that causes severe merge conflicts between drm-next and Linus' tree about every single day? (sorry, couldn't resist ;-)

Yeah, for a subsystem that only consists of 10% of the overall kernel (by patch count) we do an extremly shitty job. Maybe we should just all slow down and stop merging support for new hw, and fuck Android and CrOS and the billions of devices that don't ship upstream, who cares about those folks.

If you're this good at mainting gpu and display subsystems, maybe you want to take over? -Daniel

Hello,

On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:

...

Wut. We have like 20+ small atomic drivers nowdays.

That's fast! Only two weeks ago you said:

| Bummer, they still haven't landed. But afaik there's at least 4 of | them floating around in various places ...

You're not talking about the same thing I believe.

When Daniel says "small atomic drivers", he talks about the relatively small DRM drivers for SoC display controllers, such as the ones you can find in ARM SoCs.

When you say "small driver", you're thinking about drivers for I2C or SPI connected displays.

Best regards,

Thomas

[back from my walk, the sunset here is stellar ;-)]

On Thu, Dec 08, 2016 at 03:44:30PM +0100, Geert Uytterhoeven wrote:

Hi Thomas,

On Thu, Dec 8, 2016 at 3:37 PM, Thomas Petazzoni thomas.petazzoni@free-electrons.com wrote:

...

On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:

...

...

Wut. We have like 20+ small atomic drivers nowdays.

That's fast! Only two weeks ago you said:

| Bummer, they still haven't landed. But afaik there's at least 4 of | them floating around in various places ...

You're not talking about the same thing I believe.

When Daniel says "small atomic drivers", he talks about the relatively small DRM drivers for SoC display controllers, such as the ones you can find in ARM SoCs.

When you say "small driver", you're thinking about drivers for I2C or SPI connected displays.

No, I wasn't thinking about I2C or SPI connected displays, but about simple dumb memory-mapped frame buffers, which is what fbdev was initially developed for.

Yeah, small drivers like these we have piles now, things exploded a lot after atomic landed two years ago. And they seem to shrink with every release a bit more (since lots more drivers gives you lots more insight into what other refactorings would make sense). Those we have a big pile of, and nowadays (at least with developers expirienced with upstream, but not necessarily with drm) it takes but a few weeks from initial submission to getting them merged.

What we don't yet have a nice tidy example driver of is the even simpler "dumb framebuffer behind a slow bus with explicit/manual upload", for like small i2c/spi panels (and conceptually also usb, even though there bw and panel size are a bit scaled up). We've gained some really nice helpers for this this year, and there's 3 drivers in-flight to make use of it. But since that's right now just a hobbyist effort it's moving a bit slower (and I was mistaken a few weeks back where I assumed that one of them landed already).

Cheers, Daniel

On Fri, 2016-12-09 at 08:34 +1100, Benjamin Herrenschmidt wrote:

As I mentioned earlier, probably 1 or 2 years ago, Dave made the argument that shadowing through memory was necessary and precluded 2D accel, though I don't fully remember the root of the argument. If that is indeed not the case, then my main objection is lifted.

Things seem to change quickly as Daniel pointed out.

So ast and cirrus seem to still use a manual dirty tracking and shadowing (though I'm not sure why), but the infrastructure for that has moved from the drivers to the helpers.

bochs (qemu) doesn't seem to anymore from what I can see as it doesn't have a ->dirty callback.

Cheers, Ben.

On Fri, Dec 09, 2016 at 09:34:42AM +0100, Daniel Vetter wrote:

On Fri, Dec 09, 2016 at 08:57:29AM +1100, Benjamin Herrenschmidt wrote:

...

On Fri, 2016-12-09 at 08:34 +1100, Benjamin Herrenschmidt wrote:

...

As I mentioned earlier, probably 1 or 2 years ago, Dave made the argument that shadowing through memory was necessary and precluded 2D accel, though I don't fully remember the root of the argument. If that is indeed not the case, then my main objection is lifted.

Things seem to change quickly as Daniel pointed out.

So ast and cirrus seem to still use a manual dirty tracking and shadowing (though I'm not sure why), but the infrastructure for that has moved from the drivers to the helpers.

bochs (qemu) doesn't seem to anymore from what I can see as it doesn't have a ->dirty callback.

Yeah if you have discrete vram then your dumb display driver isn't all that pretty. We essentially just have the few drivers Dave hacked up to be able to boot some servers. And there's definitely lots of room for more shared code for those, and also some better infrastructure and helpers to share more cod and make them better.

And since I failed to make this clear: There's not really a fundamental reason ast and cirrus use the dirty tracking for fbdev. It's just that doing it that way was the fastest way to get those servers booting, and ever since no one cared. It's a bit tricky to do right because fbdev assumes it always own the framebuffer and that it never moves, whereas drm has a multi-master model and proper isolation. IIrc we've hacked up something once, and if there's indeed more interest into vram dumb buffer drivers I'm pretty sure we can grow some nice ttm fb helpers (like the cma fb helpers we have) to make it all pretty and nice and fast and essentially plug-in-and-forget from a driver authors pov.

Cheers, Daniel

The massive pile of dumb framebuffers we all merged over the past 2 years all use system/dma memory for scanout, and for those we have the very nice cma helpers that take care of everything for you. So it is possible, only reason vram dumb buffers look worse is that there's only 3 and no one cares about them, vs about 20 and a very active community of contributors (also for core drm improvements) for the other case.

Althought the MXSFB driver that just landed does use ttm and vram, so maybe that's now improving too.

-Daniel

Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

On Fri, Dec 09, 2016 at 10:48:07PM +1100, Benjamin Herrenschmidt wrote:

On Fri, 2016-12-09 at 09:41 +0100, Daniel Vetter wrote:

...

And since I failed to make this clear: There's not really a fundamental reason ast and cirrus use the dirty tracking for fbdev. It's just that doing it that way was the fastest way to get those servers booting, and ever since no one cared. It's a bit tricky to do right because fbdev assumes it always own the framebuffer and that it never moves,

That can be worked around from my memories of hacking fbdev many years ago. Basically fbdev only owns it if it's the current VT and you can make it release it if the user switches to KD_GRAPHICS which userspace should always do before taking over.

As for multi userspace client, well, swapping an mmap between HW and memory backing store is a somewhat solved problem already.

Hm, I didn't know that, but then all existing drm drivers have fairly simplistic fbdev mmap implementations.

...

whereas drm has a multi-master model and proper isolation. IIrc we've hacked up something once, and if there's indeed more interest into vram dumb buffer drivers I'm pretty sure we can grow some nice ttm fb helpers (like the cma fb helpers we have) to make it all pretty and nice and fast and essentially plug-in-and-forget from a driver authors pov.

That would be nice. I don't have the bandwidth to swap-in enough understanding of TTM guts right now but I might look into it some time next  year if nobody beats me to it.

Probably best would be to first extract some helpers for ttm based vram dumb buffer management, and then start to implement some of the improvements so that all drivers can benefit. Like you've said it's not rocket science, it just needs to be done ;-) -Daniel

On 10/12/16 05:27 AM, Benjamin Herrenschmidt wrote:

On Fri, 2016-12-09 at 14:35 +0100, Daniel Vetter wrote:

...

...

As for multi userspace client, well, swapping an mmap between HW and memory backing store is a somewhat solved problem already.

Hm, I didn't know that, but then all existing drm drivers have fairly simplistic fbdev mmap implementations.

Hrm, I though the TTM did it ... I remember talking with Thomas Hellstrom about that back in the day... you use unmap_mapping_range to unmap the existing mappings basically so you can take new faults and route them to a different page, but I can't see a call in there so maybe he ended up not doing it.

I think he did, it was working fine for userspace mappings when I tried making radeon use a non-pinned BO for fbdev years ago (the problem was fbcon potentially trying to access the framebuffer at the most inconvenient times). There's still ttm_fbdev_mmap, but I'm not sure everything to make this fully work for userspace fbdev mappings is still there.

Hi Ben,

On Fri, Dec 9, 2016 at 12:44 PM, Benjamin Herrenschmidt benh@kernel.crashing.org wrote:

...

So it is possible, only reason vram dumb buffers look worse is that there's only 3 and no one cares about them, vs about 20 and a very active community of contributors (also for core drm improvements) for the other case.

Well, we could move offb to drm while at it I suppose that would be another one (offb is the "dumb driver based on pre-programmed output by firmware).

That would indeed be a great example.

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 Fri, Dec 09, 2016 at 10:44:16PM +1100, Benjamin Herrenschmidt wrote:

On Fri, 2016-12-09 at 09:34 +0100, Daniel Vetter wrote:

...

Yeah if you have discrete vram then your dumb display driver isn't all that pretty. We essentially just have the few drivers Dave hacked up to be able to boot some servers. And there's definitely lots of room for more shared code for those, and also some better infrastructure and helpers to share more cod and make them better.

The massive pile of dumb framebuffers we all merged over the past 2 years all use system/dma memory for scanout, and for those we have the very nice cma helpers that take care of everything for you.

Do they work if the system/DMA memory has to be physically contiguous and at a fixed address ? The AST "ARM side" GPU is like that.

Yeah, if you wire up the dma_alloc_coherent to cma you'll get a contiguous buffer pinned into place.

...

So it is possible, only reason vram dumb buffers look worse is that there's only 3 and no one cares about them, vs about 20 and a very active community of contributors (also for core drm improvements) for the other case.

Well, we could move offb to drm while at it I suppose that would be another one (offb is the "dumb driver based on pre-programmed output by firmware).

One of the still in-flight drm drivers is the simpledrm thing meant for all kinds of firmware drivers like efifb and similar things on arm for pre-programmed output set up by firmware. I.e. no modeset support and otherwise a lot of fake to make it work as drm driver, but the idea that it's good enough until your real drm driver takes over. -Daniel

On Fri, Dec 09, 2016 at 02:57:24PM +0100, David Herrmann wrote:

Hey

On Fri, Dec 9, 2016 at 2:33 PM, Daniel Vetter daniel@ffwll.ch wrote:

...

...

...

So it is possible, only reason vram dumb buffers look worse is that there's only 3 and no one cares about them, vs about 20 and a very active community of contributors (also for core drm improvements) for the other case.

Well, we could move offb to drm while at it I suppose that would be another one (offb is the "dumb driver based on pre-programmed output by firmware).

One of the still in-flight drm drivers is the simpledrm thing meant for all kinds of firmware drivers like efifb and similar things on arm for pre-programmed output set up by firmware. I.e. no modeset support and otherwise a lot of fake to make it work as drm driver, but the idea that it's good enough until your real drm driver takes over.

The x86 platform device fixups for SimpleDRM went in some weeks ago, so maybe I should resend the patches. The driver could easily do 'offb'-like devices as well. Trivial to add.

Anyway, Benjamin is right, we always do shadow buffering for trivial drivers. Even in SimpleDRM I blit the shadow buffer on page-flip or dirty-ioctl. Reason is that we cannot easily expose the real framebuffer in DRM via FB-objects. But I also never saw a use-case for it, since all trivial devices I worked with were only either used as fallback or nobody cared for performance.

The generic DRM API is designed for dynamic FB allocation. If your hardware does not allow you to change the scanout source, you will have a hard time trying to expose the static buffers via the dynamic FB-object API. Furthermore, all DRM user-space expects dynamic FB management to work, preferably without a ridiculously low memory limit. That's also why I never bothered changing the drivers.

Despite all of this I still see no reason why a driver could not expose the static, real frambuffers via private ioctls. You can get all your fancy acceleration that way. Then fix user-space to use this API. If enough drivers end up with something similar, move it into the core. Just like we always do in DRM.

Well, we don't need a private abi. If we dynamically remap the mmaps and fixup fbdev to do the same then we could redirect frontbuffer rendering for the currently displaying buffer to the static, real framebuffer. That would fix the perf issues Ben is fearing I think.

And if we do some nice ttm helpers to hide this all to the level the cma helpers are just plug-in-and-go then it'd be real nice I think. But thus far no one has cared enough yet to make that happen. -Daniel

On Thu, Dec 08, 2016 at 04:21:34PM +0100, Daniel Vetter wrote:

[back from my walk, the sunset here is stellar ;-)]

On Thu, Dec 08, 2016 at 03:44:30PM +0100, Geert Uytterhoeven wrote:

...

Hi Thomas,

On Thu, Dec 8, 2016 at 3:37 PM, Thomas Petazzoni thomas.petazzoni@free-electrons.com wrote:

...

On Thu, 8 Dec 2016 15:22:09 +0100, Geert Uytterhoeven wrote:

...

...

Wut. We have like 20+ small atomic drivers nowdays.

That's fast! Only two weeks ago you said:

| Bummer, they still haven't landed. But afaik there's at least 4 of | them floating around in various places ...

You're not talking about the same thing I believe.

When Daniel says "small atomic drivers", he talks about the relatively small DRM drivers for SoC display controllers, such as the ones you can find in ARM SoCs.

When you say "small driver", you're thinking about drivers for I2C or SPI connected displays.

No, I wasn't thinking about I2C or SPI connected displays, but about simple dumb memory-mapped frame buffers, which is what fbdev was initially developed for.

Yeah, small drivers like these we have piles now, things exploded a lot after atomic landed two years ago. And they seem to shrink with every release a bit more (since lots more drivers gives you lots more insight into what other refactorings would make sense). Those we have a big pile of, and nowadays (at least with developers expirienced with upstream, but not necessarily with drm) it takes but a few weeks from initial submission to getting them merged.

What we don't yet have a nice tidy example driver of is the even simpler "dumb framebuffer behind a slow bus with explicit/manual upload", for like small i2c/spi panels (and conceptually also usb, even though there bw and panel size are a bit scaled up). We've gained some really nice helpers for this this year, and there's 3 drivers in-flight to make use of it. But since that's right now just a hobbyist effort it's moving a bit slower (and I was mistaken a few weeks back where I assumed that one of them landed already).

Correction, MXSFB just landed, which is the first driver using the simple display pipe helpers. -Daniel

Dear dri-devel folks,

My sincere apologies for hitting send on that mail. I got real mad and angry and typed a mail I shouldn't have submitted - pouring oil into flames for shit and giggles just doesn't help anyone, and it detracts from moving things forward and improving the code and drivers and everything in a friendly and constructive fashion. I want to be part of a great community, this wasnt :(

/me out and off for a walk

Thanks, Daniel

On Thu, Dec 08, 2016 at 03:02:10PM +0100, Daniel Vetter wrote:

On Thu, Dec 08, 2016 at 01:15:56PM +0100, Geert Uytterhoeven wrote:

...

On Thu, Dec 8, 2016 at 11:10 AM, Daniel Vetter daniel@ffwll.ch wrote:

...

On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:

...

On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:

...

Since the fbdev framework is in maintenance mode and all new display drivers should be made with the DRM framework, remove the fbdev drivers from staging.

Note: the patches are created with git format-patch -D, so they can't be applied. Only for review.

I missed the discussion where this decision was made, I admit I am unimpressed by it.

DRM drivers don't strike me as suitable for small/slow cores with dumb framebuffers or simple 2D only accel, such as the one found in the ASpeed BMCs.

We have a helper for simple drivers now, if you take into account the massive helper libraries for everything that comes along with drm I expect if even dumb panels behind slow spi buses drm is now the more suitable subsytem.

This has been going on your years:

1. Fbdev is obsolete, everybody should use DRM instead!
2. Can you please point me to a small sample driver for a dumb frame buffer?
3. Several are being written, but none of them is upstream yet.
4. Goto 1.

Wut. We have like 20+ small atomic drivers nowdays.

...

...

...

With drmfb you basically have to shadow everything into memory & copy over everything, and locks you out of simple 2D accel. For a simple text console the result is orders of magnitude slower and memory hungry than a simple fbdev.

Not true, we have full fbdev emulation, and drivers can implement the 2d accel in there. And a bunch of them do. It's just that most teams decided that this is pointless waste of their time.j

...

At least that was the case last I looked at the DRM stuff with Dave, maybe things have changed...

Not everything has a powerful 3D GPU.

That's correct, and drm can cope. And compared to fbdev there's a very active community who improves&refactors it every kernel release to make it even better. Since about 2 years (when atomic landed) we merge new drivers at a rate of 2-3 per kernel release, and those new drivers get ever simpler and smaller thanks to all this work.

You mean the kind of refactoring that causes severe merge conflicts between drm-next and Linus' tree about every single day? (sorry, couldn't resist ;-)

Yeah, for a subsystem that only consists of 10% of the overall kernel (by patch count) we do an extremly shitty job. Maybe we should just all slow down and stop merging support for new hw, and fuck Android and CrOS and the billions of devices that don't ship upstream, who cares about those folks.

If you're this good at mainting gpu and display subsystems, maybe you want to take over?

-Daniel

Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

On 9 December 2016 at 07:28, Benjamin Herrenschmidt benh@kernel.crashing.org wrote:

On Thu, 2016-12-08 at 11:10 +0100, Daniel Vetter wrote:

...

...

With drmfb you basically have to shadow everything into memory & copy over everything, and locks you out of simple 2D accel. For a simple text console the result is orders of magnitude slower and memory hungry than a simple fbdev.

Not true, we have full fbdev emulation, and drivers can implement the 2d accel in there. And a bunch of them do. It's just that most teams decided that this is pointless waste of their time.j

Ok so my knowledge might be outdated here. I was complaining to Dave about how cirrusdrmfb didn't even use blits for fbcon scrolling and always double buffered everything, and Dave made the point that you basically had to do that for security reasons that I mostly forgot the details of.

It looks like bochsdrmfb and astdrmfb are the same. If things have changed, then cool. Can you point me to a drmfb driver that is a good (and not too complex) example with simple 2d accel ? I'm thinking mostly of color expansion, bitblt and solid fill for fbcon, the way I used to do it in radeonfb for example.

What are people using fbcon for that needs acceleration, this is where I get a bit lost.

It's a console, if you aren't sshing into the machine.

It's main purpose should just be for gathering oopses and you've a lot better chance of getting an oops if you don't have some sketchy gpu accel in the way.

The acceleration that most of the 2D things provide isn't ever that great, and shadowing is a lot more effective if done properly. It's a feature that kernel ppl obsess over but I don't get a lot of real world feedback, (booting 9000 scsi nodes with debug on takes a long time was possibly something I heard once, and I think we resolved).

Dave.

On Fri, 2016-12-09 at 10:08 +1000, Dave Airlie wrote:

What are people using fbcon for that needs acceleration, this is where I get a bit lost.

It's a console, if you aren't sshing into the machine.

It's main purpose should just be for gathering oopses and you've a lot better chance of getting an oops if you don't have some sketchy gpu accel in the way.

There are other uses for systems running Linux than being a server or desktop :-)

The acceleration that most of the 2D things provide isn't ever that great, and shadowing is a lot more effective if done properly.

Not with a 400Mhz ARM9 processor on a fairly high res display. In these case basic old things like color expansion for font rendering, bit blits and solid fills for scrolls work beautifully. Anyway I just realized that the ARM side of the AST GPU doesn't have the accel bits at all anyway, only the host side, so I'm back to just a dumb FB. I still want to avoid the copies though.

It's a feature that kernel ppl obsess over but I don't get a lot of real world feedback, (booting 9000 scsi nodes with debug on takes a long time was possibly something I heard once, and I think we resolved).

Ben.

Hi Daniel,

On Thursday 08 Dec 2016 11:10:05 Daniel Vetter wrote:

On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote:

...

On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote:

...

Hi,

Since the fbdev framework is in maintenance mode and all new display drivers should be made with the DRM framework, remove the fbdev drivers from staging.

Note: the patches are created with git format-patch -D, so they can't be applied. Only for review.

I missed the discussion where this decision was made, I admit I am unimpressed by it.

DRM drivers don't strike me as suitable for small/slow cores with dumb framebuffers or simple 2D only accel, such as the one found in the ASpeed BMCs.

We have a helper for simple drivers now, if you take into account the massive helper libraries for everything that comes along with drm I expect if even dumb panels behind slow spi buses drm is now the more suitable subsytem.

...

With drmfb you basically have to shadow everything into memory & copy over everything, and locks you out of simple 2D accel. For a simple text console the result is orders of magnitude slower and memory hungry than a simple fbdev.

Not true, we have full fbdev emulation, and drivers can implement the 2d accel in there. And a bunch of them do. It's just that most teams decided that this is pointless waste of their time.j

And I'd argue that a better use of time would be to implement an accelerated console that does not use fbdev at all.

...

At least that was the case last I looked at the DRM stuff with Dave, maybe things have changed...

Not everything has a powerful 3D GPU.

That's correct, and drm can cope. And compared to fbdev there's a very active community who improves&refactors it every kernel release to make it even better. Since about 2 years (when atomic landed) we merge new drivers at a rate of 2-3 per kernel release, and those new drivers get ever simpler and smaller thanks to all this work.