On Mon, 21 Mar 2011 19:19:43 +0000
timofonic timofonic [off-list ref] 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
On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes [off-list ref] wrote:
On Mon, 21 Mar 2011 19:19:43 +0000
timofonic timofonic [off-list ref] wrote:
quoted
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.
quoted
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
[off-list ref]
On Mon, Mar 21, 2011 at 20:25, Jesse Barnes [off-list ref] wrote:
On Mon, 21 Mar 2011 19:19:43 +0000
timofonic timofonic [off-list ref] wrote:
quoted
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 ...
quoted
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
On Mon, 21 Mar 2011 20:50:20 +0100
Geert Uytterhoeven [off-list ref] wrote:
On Mon, Mar 21, 2011 at 20:25, Jesse Barnes [off-list ref] wrote:
quoted
On Mon, 21 Mar 2011 19:19:43 +0000
timofonic timofonic [off-list ref] wrote:
quoted
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. :)
quoted
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
On Mon, 21 Mar 2011 12:34:38 -0700
Corbin Simpson [off-list ref] 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
From: Alex Deucher <hidden> Date: 2011-03-21 20:08:36
On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven
[off-list ref] wrote:
On Mon, Mar 21, 2011 at 20:25, Jesse Barnes [off-list ref] wrote:
quoted
On Mon, 21 Mar 2011 19:19:43 +0000
timofonic timofonic [off-list ref] wrote:
quoted
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
quoted
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 ...
quoted
quoted
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
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)
From: Ondrej Zary <hidden> Date: 2011-03-21 21:20:48
On Monday 21 March 2011 20:34:38 Corbin Simpson wrote:
On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes [off-list ref]
wrote:
quoted
On Mon, 21 Mar 2011 19:19:43 +0000
timofonic timofonic [off-list ref] wrote:
quoted
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.
quoted
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.
From: Matt Turner <mattst88@gmail.com> Date: 2011-03-21 21:37:47
On Mon, Mar 21, 2011 at 9:20 PM, Alan Cox [off-list ref] wrote:
quoted
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
From: Alex Deucher <hidden> Date: 2011-03-21 21:46:27
On Mon, Mar 21, 2011 at 5:13 PM, Ondrej Zary [off-list ref] wrote:
On Monday 21 March 2011 20:34:38 Corbin Simpson wrote:
quoted
On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes [off-list ref]
wrote:
quoted
quoted
On Mon, 21 Mar 2011 19:19:43 +0000
timofonic timofonic [off-list ref] wrote:
quoted
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.
quoted
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
quoted
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.
From: Michal Suchanek <hidden> Date: 2011-03-22 15:26:43
On 21 March 2011 20:25, Jesse Barnes [off-list ref] wrote:
On Mon, 21 Mar 2011 19:19:43 +0000
timofonic timofonic [off-list ref] wrote:
quoted
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
From: Robert Fekete <hidden> Date: 2011-03-23 14:09:55
On 21 March 2011 21:08, Alex Deucher [off-list ref] wrote:
On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven
[off-list ref] wrote:
quoted
On Mon, Mar 21, 2011 at 20:25, Jesse Barnes [off-list ref] wrote:
quoted
On Mon, 21 Mar 2011 19:19:43 +0000
timofonic timofonic [off-list ref] wrote:
quoted
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
On Wednesday 23 March 2011 15:09:54 Robert Fekete wrote:
On 21 March 2011 21:08, Alex Deucher [off-list ref] wrote:
quoted
On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven wrote:
quoted
On Mon, Mar 21, 2011 at 20:25, Jesse Barnes wrote:
quoted
On Mon, 21 Mar 2011 19:19:43 +0000 timofonic timofonic wrote:
quoted
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.
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)