Future desktop on dumb frame buffers?

Future desktop on dumb frame buffers?

[Geert Uytterhoeven]

As noone responded to my question in
http://www.spinics.net/lists/dri-devel/msg08851.html
(yes, it was a bit hidden in a thread), I'm asking it here again (and
also on the Wayland
mailing list).

Basically I'm still puzzled about this KMS thing. If the name "Kernel
Mode Setting"
covers it, then how does it compare to plain fbdev? Just additional frame buffer
memory management?
Also, some people may remember we did have kernel messages (e.g. oops, panic)
on graphical consoles with fbdev, until people started not liking them
showing up
on their X desktops...

Furthermore, everybody states that "future desktop" (that's
http://wayland.freedesktop.org/)
will require KMS drivers.
How do/will we handle this on dumb frame buffers? It's not like we can't do
"advanced" things like compositing using the CPU. Transparency may stretch
it a bit on lower end CPUs, but you don't always need that.

Thanks for your answers and comments!

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

Re: Future desktop on dumb frame buffers?

[Rob Clark]

On Sat, Mar 19, 2011 at 6:20 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> As noone responded to my question in
> http://www.spinics.net/lists/dri-devel/msg08851.html
> (yes, it was a bit hidden in a thread), I'm asking it here again (and
> also on the Wayland
> mailing list).
>
> Basically I'm still puzzled about this KMS thing. If the name "Kernel
> Mode Setting"
> covers it, then how does it compare to plain fbdev? Just additional frame buffer
> memory management?
> Also, some people may remember we did have kernel messages (e.g. oops, panic)
> on graphical consoles with fbdev, until people started not liking them
> showing up
> on their X desktops...

The KMS part of DRM has nothing to do with acceleration.  So it could
be implemented on a dumb framebuffer.  KMS is just about mode-setting,
and configuring framebuffer (memory) that is scanned out to one or
more displays.

BR,
-R

> Furthermore, everybody states that "future desktop" (that's
> http://wayland.freedesktop.org/)
> will require KMS drivers.
> How do/will we handle this on dumb frame buffers? It's not like we can't do
> "advanced" things like compositing using the CPU. Transparency may stretch
> it a bit on lower end CPUs, but you don't always need that.
>
> Thanks for your answers and comments!
>
> 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
>

Re: Future desktop on dumb frame buffers?

[Jesse Barnes]

On Sat, 19 Mar 2011 12:20:24 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> As noone responded to my question in
> http://www.spinics.net/lists/dri-devel/msg08851.html
> (yes, it was a bit hidden in a thread), I'm asking it here again (and
> also on the Wayland
> mailing list).
> 
> Basically I'm still puzzled about this KMS thing. If the name "Kernel
> Mode Setting"
> covers it, then how does it compare to plain fbdev? Just additional frame buffer
> memory management?
> Also, some people may remember we did have kernel messages (e.g. oops, panic)
> on graphical consoles with fbdev, until people started not liking them
> showing up
> on their X desktops...

We support panic these days as well, but people still don't like seeing
them. :)

The DRM KMS APIs provide everything fbdev provides, plus memory
management, a way to expose acceleration (via GEM or TTM), and a way to
manage multiple outputs reasonably.

> Furthermore, everybody states that "future desktop" (that's
> http://wayland.freedesktop.org/)
> will require KMS drivers.
> How do/will we handle this on dumb frame buffers? It's not like we can't do
> "advanced" things like compositing using the CPU. Transparency may stretch
> it a bit on lower end CPUs, but you don't always need that.

There's nothing in DRM that precludes doing simple fbdev-like drivers
as well, though for many embedded uses I wouldn't expect it to provide
a whole lot of benefit.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: Future desktop on dumb frame buffers?

[timofonic timofonic]

Hello.

I have some rants and questions about fbdev, KMS and graphics stuff to
Linux. I'm just a mere user and occasional system administrator (and
going to start computer programming soon), but I hope to be able to
understand this situation better.

So if KMS is so cool and provides many advantages over fbdev and
such... Why isn't more widely used intead of still relying on fbdev?
Why still using fbdev emulation (that is partial and somewhat broken,
it seems) instead using KMS directly?

I know the graphic driver situation is quite bad on Linux, especially
on the embedded world. Fbdev seems is still quite used there by binary
blob drivers.

I was a fan of projects like DirectFB and such, but it seems they lack
the manpower or fuel to keep the project relevant. Maybe Wayland can
be their substitute and even have a broader usage too.

I hope KMS gets stronger and the graphic drivers get more into the
open source world (instead violating GPL and doing an attitude I think
should be illegal), that news about open source PowerVR SGX drivers
seems very positive (and surprising, because Imagination Technologies
seems quite against FOSS).

I hope all this gets to suck a bit less. Linux graphics stack
foundation based on KMS, TTM/GEM, advanced hardware accelerated video
decoding of most formats (by using OpenCL plus FFMpeg/LibAV, for
example), Gallium3D and full OpenGL 4.x support could make me very
happy as user and future developer...

Sadly, stuff like S3TC and such makes me very sad. I hope it gets
resolved sucessfully, patents are the nightmare of the technology...


Regards.

On Mon, Mar 21, 2011 at 6:00 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Sat, 19 Mar 2011 12:20:24 +0100
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
>> As noone responded to my question in
>> http://www.spinics.net/lists/dri-devel/msg08851.html
>> (yes, it was a bit hidden in a thread), I'm asking it here again (and
>> also on the Wayland
>> mailing list).
>>
>> Basically I'm still puzzled about this KMS thing. If the name "Kernel
>> Mode Setting"
>> covers it, then how does it compare to plain fbdev? Just additional frame buffer
>> memory management?
>> Also, some people may remember we did have kernel messages (e.g. oops, panic)
>> on graphical consoles with fbdev, until people started not liking them
>> showing up
>> on their X desktops...
>
> We support panic these days as well, but people still don't like seeing
> them. :)
>
> The DRM KMS APIs provide everything fbdev provides, plus memory
> management, a way to expose acceleration (via GEM or TTM), and a way to
> manage multiple outputs reasonably.
>
>> Furthermore, everybody states that "future desktop" (that's
>> http://wayland.freedesktop.org/)
>> will require KMS drivers.
>> How do/will we handle this on dumb frame buffers? It's not like we can't do
>> "advanced" things like compositing using the CPU. Transparency may stretch
>> it a bit on lower end CPUs, but you don't always need that.
>
> There's nothing in DRM that precludes doing simple fbdev-like drivers
> as well, though for many embedded uses I wouldn't expect it to provide
> a whole lot of benefit.
>
> --
> Jesse Barnes, Intel Open Source Technology Center
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>

Re: Future desktop on dumb frame buffers?

[Jesse Barnes]

On Mon, 21 Mar 2011 19:19:43 +0000
timofonic timofonic <timofonic@gmail.com> wrote:
> So if KMS is so cool and provides many advantages over fbdev and
> such... Why isn't more widely used intead of still relying on fbdev?
> Why still using fbdev emulation (that is partial and somewhat broken,
> it seems) instead using KMS directly?

Used by what?  All three major GPU device classes have KMS support
(Intel, ATI, and nVidia).  If you want it for a particular device, you
can always port it over.

As for fbdev emulation, what's still using it?  There's nothing
stopping projects from converting over; X and Wayland can already
handle KMS APIs just fine.

> I know the graphic driver situation is quite bad on Linux, especially
> on the embedded world. Fbdev seems is still quite used there by binary
> blob drivers.

Probably for a couple of reasons:
  1) inertia: fbdev has been around a lot longer, and provides most of
  what embedded devices need anyway
  2) feature set: why bother doing a full KMS driver if you're not
  going to use any of the additional features it would provide (output
  management, memory management, execution management)

Jesse

Re: Future desktop on dumb frame buffers?

[Corbin Simpson]

On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Mon, 21 Mar 2011 19:19:43 +0000
> timofonic timofonic <timofonic@gmail.com> wrote:
>> So if KMS is so cool and provides many advantages over fbdev and
>> such... Why isn't more widely used intead of still relying on fbdev?
>> Why still using fbdev emulation (that is partial and somewhat broken,
>> it seems) instead using KMS directly?
>
> Used by what?  All three major GPU device classes have KMS support
> (Intel, ATI, and nVidia).  If you want it for a particular device, you
> can always port it over.
>
> As for fbdev emulation, what's still using it?  There's nothing
> stopping projects from converting over; X and Wayland can already
> handle KMS APIs just fine.
>
>> I know the graphic driver situation is quite bad on Linux, especially
>> on the embedded world. Fbdev seems is still quite used there by binary
>> blob drivers.
>
> Probably for a couple of reasons:
>  1) inertia: fbdev has been around a lot longer, and provides most of
>  what embedded devices need anyway
>  2) feature set: why bother doing a full KMS driver if you're not
>  going to use any of the additional features it would provide (output
>  management, memory management, execution management)

Related: We are still missing basic userspace tools (kmsset, e.g.),
some kind of direct KMS console (kmscon would work, if it existed),
and an xf86-video-modesetting which compiles and works (this is
actually possible now, with some patches that landed in 2.6.38 for
generic KMS access.)

This is important to me, as the various old drivers I've been hacking
on won't be accepted upstream without some sort of userspace which can
work with them. One of the big goals of KMS was a generic
userspace-facing API, like FB, but without the suck.

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude@gmail.com>

Re: Future desktop on dumb frame buffers?

[Geert Uytterhoeven]

On Mon, Mar 21, 2011 at 20:25, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Mon, 21 Mar 2011 19:19:43 +0000
> timofonic timofonic <timofonic@gmail.com> wrote:
>> So if KMS is so cool and provides many advantages over fbdev and
>> such... Why isn't more widely used intead of still relying on fbdev?
>> Why still using fbdev emulation (that is partial and somewhat broken,
>> it seems) instead using KMS directly?
>
> Used by what?  All three major GPU device classes have KMS support
> (Intel, ATI, and nVidia).  If you want it for a particular device, you
> can always port it over.

The three major GPU device classes on PC...

> As for fbdev emulation, what's still using it?  There's nothing
> stopping projects from converting over; X and Wayland can already
> handle KMS APIs just fine.

Can Wayland handle fbdev APIs ...

>> I know the graphic driver situation is quite bad on Linux, especially
>> on the embedded world. Fbdev seems is still quite used there by binary
>> blob drivers.
>
> Probably for a couple of reasons:
>  1) inertia: fbdev has been around a lot longer, and provides most of
>  what embedded devices need anyway
>  2) feature set: why bother doing a full KMS driver if you're not
>  going to use any of the additional features it would provide (output
>  management, memory management, execution management)

... if no additional features of KMS are needed?

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

Re: Future desktop on dumb frame buffers?

[Jesse Barnes]

On Mon, 21 Mar 2011 20:50:20 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > On Mon, 21 Mar 2011 19:19:43 +0000
> > timofonic timofonic <timofonic@gmail.com> wrote:
> >> So if KMS is so cool and provides many advantages over fbdev and
> >> such... Why isn't more widely used intead of still relying on fbdev?
> >> Why still using fbdev emulation (that is partial and somewhat broken,
> >> it seems) instead using KMS directly?
> >
> > Used by what?  All three major GPU device classes have KMS support
> > (Intel, ATI, and nVidia).  If you want it for a particular device, you
> > can always port it over.
> 
> The three major GPU device classes on PC...

Yes, good point. :)

> > As for fbdev emulation, what's still using it?  There's nothing
> > stopping projects from converting over; X and Wayland can already
> > handle KMS APIs just fine.
> 
> Can Wayland handle fbdev APIs ...

Yes.  Fundamentally, the Wayland protocol just assumes a way to share
buffers between processes.  For the software raster version of the Qt
port, Kristian created a shmem interface for doing that to allow the
results of CPU rendering to be passed around without copying.  On an
embedded device that would be one way to go.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: Future desktop on dumb frame buffers?

[Jesse Barnes]

On Mon, 21 Mar 2011 12:34:38 -0700
Corbin Simpson <mostawesomedude@gmail.com> wrote:
> Related: We are still missing basic userspace tools (kmsset, e.g.),
> some kind of direct KMS console (kmscon would work, if it existed),
> and an xf86-video-modesetting which compiles and works (this is
> actually possible now, with some patches that landed in 2.6.38 for
> generic KMS access.)

Yeah, we used to call that drmcon, and it's still a big open.  I think
there are some projects that sit on top of fbdev and provide a good
text console with fancy character and input support, but I don't know
if any of them have been ported to KMS to handle multiple outputs or
with an aim toward integrating into a distro as a VT replacement.

kmsset or something would be pretty easy to do; the modetest program in
the drm repo would be a good starting point for that.  One limitation
there is handling fbcon, which makes reallocation of the framebuffer
somewhat difficult.

IIRC plymouth or whatever Fedora is using these days uses the KMS APIs
though...

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: Future desktop on dumb frame buffers?

[Alex Deucher]

On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>> On Mon, 21 Mar 2011 19:19:43 +0000
>> timofonic timofonic <timofonic@gmail.com> wrote:
>>> So if KMS is so cool and provides many advantages over fbdev and
>>> such... Why isn't more widely used intead of still relying on fbdev?
>>> Why still using fbdev emulation (that is partial and somewhat broken,
>>> it seems) instead using KMS directly?
>>
>> Used by what?  All three major GPU device classes have KMS support
>> (Intel, ATI, and nVidia).  If you want it for a particular device, you
>> can always port it over.
>
> The three major GPU device classes on PC...

Sadly it gets worse.  A lot of the SoC vendors are adding an fbdev
emulation layer on top of v4l rather than using fbdev directly or
using KMS and v4l has grown it's own edid, hdmi, and cec handling.

Alex

>
>> As for fbdev emulation, what's still using it?  There's nothing
>> stopping projects from converting over; X and Wayland can already
>> handle KMS APIs just fine.
>
> Can Wayland handle fbdev APIs ...
>
>>> I know the graphic driver situation is quite bad on Linux, especially
>>> on the embedded world. Fbdev seems is still quite used there by binary
>>> blob drivers.
>>
>> Probably for a couple of reasons:
>>  1) inertia: fbdev has been around a lot longer, and provides most of
>>  what embedded devices need anyway
>>  2) feature set: why bother doing a full KMS driver if you're not
>>  going to use any of the additional features it would provide (output
>>  management, memory management, execution management)
>
> ... if no additional features of KMS are needed?
>
> 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
>

Re: Future desktop on dumb frame buffers?

[Ondrej Zary]

On Monday 21 March 2011 20:34:38 Corbin Simpson wrote:
> On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes <jbarnes@virtuousgeek.org> 
wrote:
> > On Mon, 21 Mar 2011 19:19:43 +0000
> >
> > timofonic timofonic <timofonic@gmail.com> wrote:
> >> So if KMS is so cool and provides many advantages over fbdev and
> >> such... Why isn't more widely used intead of still relying on fbdev?
> >> Why still using fbdev emulation (that is partial and somewhat broken,
> >> it seems) instead using KMS directly?
> >
> > Used by what?  All three major GPU device classes have KMS support
> > (Intel, ATI, and nVidia).  If you want it for a particular device, you
> > can always port it over.
> >
> > As for fbdev emulation, what's still using it?  There's nothing
> > stopping projects from converting over; X and Wayland can already
> > handle KMS APIs just fine.
> >
> >> I know the graphic driver situation is quite bad on Linux, especially
> >> on the embedded world. Fbdev seems is still quite used there by binary
> >> blob drivers.
> >
> > Probably for a couple of reasons:
> >  1) inertia: fbdev has been around a lot longer, and provides most of
> >  what embedded devices need anyway
> >  2) feature set: why bother doing a full KMS driver if you're not
> >  going to use any of the additional features it would provide (output
> >  management, memory management, execution management)
>
> Related: We are still missing basic userspace tools (kmsset, e.g.),
> some kind of direct KMS console (kmscon would work, if it existed),
> and an xf86-video-modesetting which compiles and works (this is
> actually possible now, with some patches that landed in 2.6.38 for
> generic KMS access.)

This looks interesting. If existing *fb drivers could be easily converted to 
KMS (including 2D acceleration) and then used in X with a common driver, it 
would be great. Let's say, convert cyber2000fb driver to KMS and use it in X 
with 2D acceleration.

> This is important to me, as the various old drivers I've been hacking
> on won't be accepted upstream without some sort of userspace which can
> work with them. One of the big goals of KMS was a generic
> userspace-facing API, like FB, but without the suck.


-- 
Ondrej Zary

Re: Future desktop on dumb frame buffers?

[Alan Cox]

>   1) inertia: fbdev has been around a lot longer, and provides most of
>   what embedded devices need anyway
>   2) feature set: why bother doing a full KMS driver if you're not
>   going to use any of the additional features it would provide (output
>   management, memory management, execution management)

3) its got documentation

Re: Future desktop on dumb frame buffers?

[Jesse Barnes]

On Mon, 21 Mar 2011 21:20:08 +0000
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> >   1) inertia: fbdev has been around a lot longer, and provides most of
> >   what embedded devices need anyway
> >   2) feature set: why bother doing a full KMS driver if you're not
> >   going to use any of the additional features it would provide (output
> >   management, memory management, execution management)
> 
> 3) its got documentation

Jeez, some people want it all.

You looking for docs for the ioctls and such?

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: Future desktop on dumb frame buffers?

[Matt Turner]

On Mon, Mar 21, 2011 at 9:20 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>   1) inertia: fbdev has been around a lot longer, and provides most of
>>   what embedded devices need anyway
>>   2) feature set: why bother doing a full KMS driver if you're not
>>   going to use any of the additional features it would provide (output
>>   management, memory management, execution management)
>
> 3) its got documentation

My summer of code project's purpose was to create something of a
tutorial for writing a KMS driver. The code, split out into something
like 15 step-by-step patches, and accompanying documentation are
available from Google's website.

http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz

My repository (doesn't include the documentation) is available here:
http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary

There's a 'rebased' branch that contains API changes required for the
code to work with 2.6.37~.

It's nothing fantastic, but I've had a number of people tell me that
it was useful for them.

Thanks,
Matt

Re: Future desktop on dumb frame buffers?

[Alex Deucher]

On Mon, Mar 21, 2011 at 5:13 PM, Ondrej Zary <linux@rainbow-software.org> wrote:
> On Monday 21 March 2011 20:34:38 Corbin Simpson wrote:
>> On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes <jbarnes@virtuousgeek.org>
> wrote:
>> > On Mon, 21 Mar 2011 19:19:43 +0000
>> >
>> > timofonic timofonic <timofonic@gmail.com> wrote:
>> >> So if KMS is so cool and provides many advantages over fbdev and
>> >> such... Why isn't more widely used intead of still relying on fbdev?
>> >> Why still using fbdev emulation (that is partial and somewhat broken,
>> >> it seems) instead using KMS directly?
>> >
>> > Used by what?  All three major GPU device classes have KMS support
>> > (Intel, ATI, and nVidia).  If you want it for a particular device, you
>> > can always port it over.
>> >
>> > As for fbdev emulation, what's still using it?  There's nothing
>> > stopping projects from converting over; X and Wayland can already
>> > handle KMS APIs just fine.
>> >
>> >> I know the graphic driver situation is quite bad on Linux, especially
>> >> on the embedded world. Fbdev seems is still quite used there by binary
>> >> blob drivers.
>> >
>> > Probably for a couple of reasons:
>> >  1) inertia: fbdev has been around a lot longer, and provides most of
>> >  what embedded devices need anyway
>> >  2) feature set: why bother doing a full KMS driver if you're not
>> >  going to use any of the additional features it would provide (output
>> >  management, memory management, execution management)
>>
>> Related: We are still missing basic userspace tools (kmsset, e.g.),
>> some kind of direct KMS console (kmscon would work, if it existed),
>> and an xf86-video-modesetting which compiles and works (this is
>> actually possible now, with some patches that landed in 2.6.38 for
>> generic KMS access.)
>
> This looks interesting. If existing *fb drivers could be easily converted to
> KMS (including 2D acceleration) and then used in X with a common driver, it
> would be great. Let's say, convert cyber2000fb driver to KMS and use it in X
> with 2D acceleration.

You'd need to update the existing DDX to work with KMS.  Generally you
need some sort of userspace driver to allocate the buffers, deal with
acceleration alignment, build the acceleration command buffers, and
interface with X.

Alex

>
>> This is important to me, as the various old drivers I've been hacking
>> on won't be accepted upstream without some sort of userspace which can
>> work with them. One of the big goals of KMS was a generic
>> userspace-facing API, like FB, but without the suck.
>
>
> --
> Ondrej Zary
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Re: Future desktop on dumb frame buffers?

[Michal Suchanek]

On 21 March 2011 20:25, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Mon, 21 Mar 2011 19:19:43 +0000
> timofonic timofonic <timofonic@gmail.com> wrote:
>> So if KMS is so cool and provides many advantages over fbdev and
>> such... Why isn't more widely used intead of still relying on fbdev?
>> Why still using fbdev emulation (that is partial and somewhat broken,
>> it seems) instead using KMS directly?
>
> Used by what?  All three major GPU device classes have KMS support
> (Intel, ATI, and nVidia).  If you want it for a particular device, you
> can always port it over.
>
> As for fbdev emulation, what's still using it?  There's nothing
> stopping projects from converting over; X and Wayland can already
> handle KMS APIs just fine.

The console and a few terminal emulators for it I guess.

Thanks

Michal

Re: Future desktop on dumb frame buffers?

[Robert Fekete]

On 21 March 2011 21:08, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>>> On Mon, 21 Mar 2011 19:19:43 +0000
>>> timofonic timofonic <timofonic@gmail.com> wrote:
>>>> So if KMS is so cool and provides many advantages over fbdev and
>>>> such... Why isn't more widely used intead of still relying on fbdev?
>>>> Why still using fbdev emulation (that is partial and somewhat broken,
>>>> it seems) instead using KMS directly?
>>>
>>> Used by what?  All three major GPU device classes have KMS support
>>> (Intel, ATI, and nVidia).  If you want it for a particular device, you
>>> can always port it over.
>>
>> The three major GPU device classes on PC...
>
> Sadly it gets worse.  A lot of the SoC vendors are adding an fbdev
> emulation layer on top of v4l rather than using fbdev directly or
> using KMS and v4l has grown it's own edid, hdmi, and cec handling.
>

I agree, it is sad that as a SoC vendor there are different
kernel/user API's(v4l2/fbdev/drm) to choose from when implementing say
a Display controller driver. One must also remember that there are big
differences between a desktop/PC multimedia/graphics system and the
ones present on an embedded SoC. It is two very different cultures and
HW designs now trying to merge into one Linux Kernel. Of course there
will be some overlaps but I believe it can be sorted out as soon as we
understand each others different possibilities/limitations. Doing
duplicate work like HDMI will not benefit any party.

Just to list some of the differences.

- Developments within V4L2 has mainly been driven by embedded devices
while DRM is a result of desktop Graphics cards. And for some extent
also solving different problems.
- Embedded devices usually have several different hw IP's managing
displays, hdmi, camera/ISP, video codecs(h264 accellerators), DSP's,
2D blitters, Open GL ES hw, all of which have a separate device/driver
in the kernel, while on a desktop nowadays all this functionality
usually resides on ONE graphics card, hence one DRM device for all.
- DRM is closely developed in conjunction with desktop/Xorg, while X11
on an embedded device is not very 2011...wayland on the other hand is
:-), but do wayland really need the full potential of DRM/DRI or just
parts of it.
- Copying buffers is really bad for embedded devices due to lower
memory bandwidth and power consumption while on a Desktop memory
bandwidth is from an other galaxy (copying still bad but accepted it
seems), AND embedded devices of today records and plays/displays 1080p
content as well.
- Not all embedded devices have MMU's for each IP requiring physical
contiguous memory, while on a desktop MMU's have been present for
ages.
- Embedded devices are usually ARM based SoCs while x86 dominates the
Desktop/Laptop market, and functionality provided is soon the very
same.
- yada yada....The list can grow very long....There are also
similarities of course.

The outcome is that SoC vendors likes the embedded friendliness of
v4l2 and fbdev while "we" also glance at the DRM part due to its
de-facto standard on desktop environments. But from an embedded point
of view DRM lacks the support for interconnecting multiple
devices/drivers mentioned above, GEM/TTM is valid within a DRM device,
the execution/context management is not needed,, no overlays(or
similar), the coupling to DRI/X11 not wanted. SoCs like KMS/GEM but
the rest of DRM will likely not be heavily used on SoCs unless running
X11 as well. Most likely this worked on as well within the DRI
community. I can see good features all over the place(sometimes
duplicated) but not find one single guideline/API that solves all the
embedded SoC problems (which involves use-cases optimized for no-copy
cross media/drivers).

Last but not least...

On Linaro there is already discussions ongoing to solve one of the
biggest issues from a SoC point of view and that is a "System Wide
Memory manager" which manages buffer sharing and resolves no-copy use
cases between devices/drivers. Read more on the following thread:
http://lists.linaro.org/pipermail/linaro-dev/2011-March/003053.html.

BR
/Robert Fekete
st-ericsson

Re: Future desktop on dumb frame buffers?

[Laurent Pinchart]

On Wednesday 23 March 2011 15:09:54 Robert Fekete wrote:
> On 21 March 2011 21:08, Alex Deucher <alexdeucher@gmail.com> wrote:
> > On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven wrote:
> >> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes wrote:
> >>> On Mon, 21 Mar 2011 19:19:43 +0000 timofonic timofonic wrote:
> >>>> So if KMS is so cool and provides many advantages over fbdev and
> >>>> such... Why isn't more widely used intead of still relying on fbdev?
> >>>> Why still using fbdev emulation (that is partial and somewhat broken,
> >>>> it seems) instead using KMS directly?
> >>> 
> >>> Used by what?  All three major GPU device classes have KMS support
> >>> (Intel, ATI, and nVidia).  If you want it for a particular device, you
> >>> can always port it over.
> >> 
> >> The three major GPU device classes on PC...
> > 
> > Sadly it gets worse.  A lot of the SoC vendors are adding an fbdev
> > emulation layer on top of v4l rather than using fbdev directly or
> > using KMS and v4l has grown it's own edid, hdmi, and cec handling.

We're also evaluating the possibility of providing a generic fbdev emulation 
layer on top of V4L2 without requiring any device-specific fbdev code. fbdev 
isn't maintained and hasn't really evolved for quite some time now.

> I agree, it is sad that as a SoC vendor there are different
> kernel/user API's(v4l2/fbdev/drm) to choose from when implementing say
> a Display controller driver. One must also remember that there are big
> differences between a desktop/PC multimedia/graphics system and the
> ones present on an embedded SoC. It is two very different cultures and
> HW designs now trying to merge into one Linux Kernel. Of course there
> will be some overlaps but I believe it can be sorted out as soon as we
> understand each others different possibilities/limitations. Doing
> duplicate work like HDMI will not benefit any party.
> 
> Just to list some of the differences.
> 
> - Developments within V4L2 has mainly been driven by embedded devices
> while DRM is a result of desktop Graphics cards. And for some extent
> also solving different problems.
> - Embedded devices usually have several different hw IP's managing
> displays, hdmi, camera/ISP, video codecs(h264 accellerators), DSP's,
> 2D blitters, Open GL ES hw, all of which have a separate device/driver
> in the kernel, while on a desktop nowadays all this functionality
> usually resides on ONE graphics card, hence one DRM device for all.
> - DRM is closely developed in conjunction with desktop/Xorg, while X11
> on an embedded device is not very 2011...wayland on the other hand is
> 
> :-), but do wayland really need the full potential of DRM/DRI or just
> 
> parts of it.
> - Copying buffers is really bad for embedded devices due to lower
> memory bandwidth and power consumption while on a Desktop memory
> bandwidth is from an other galaxy (copying still bad but accepted it
> seems), AND embedded devices of today records and plays/displays 1080p
> content as well.
> - Not all embedded devices have MMU's for each IP requiring physical
> contiguous memory, while on a desktop MMU's have been present for
> ages.
> - Embedded devices are usually ARM based SoCs while x86 dominates the
> Desktop/Laptop market, and functionality provided is soon the very
> same.
> - yada yada....The list can grow very long....There are also
> similarities of course.
> 
> The outcome is that SoC vendors likes the embedded friendliness of
> v4l2 and fbdev while "we" also glance at the DRM part due to its
> de-facto standard on desktop environments. But from an embedded point
> of view DRM lacks the support for interconnecting multiple
> devices/drivers mentioned above, GEM/TTM is valid within a DRM device,
> the execution/context management is not needed,, no overlays(or
> similar), the coupling to DRI/X11 not wanted. SoCs like KMS/GEM but
> the rest of DRM will likely not be heavily used on SoCs unless running
> X11 as well. Most likely this worked on as well within the DRI
> community. I can see good features all over the place(sometimes
> duplicated) but not find one single guideline/API that solves all the
> embedded SoC problems (which involves use-cases optimized for no-copy
> cross media/drivers).
> 
> Last but not least...
> 
> On Linaro there is already discussions ongoing to solve one of the
> biggest issues from a SoC point of view and that is a "System Wide
> Memory manager" which manages buffer sharing and resolves no-copy use
> cases between devices/drivers. Read more on the following thread:
> http://lists.linaro.org/pipermail/linaro-dev/2011-March/003053.html.

-- 
Regards,

Laurent Pinchart

Re: Future desktop on dumb frame buffers?

[Alan Cox]

> It's nothing fantastic, but I've had a number of people tell me that
> it was useful for them.

It does document some stuff nicely - not alas the bits I need to figure
out at the moment but its definitely a nice reference to the basic setup.

(ponders Voodoo2 DRI)