On Wednesday 23 March 2011 15:09:54 Robert Fekete wrote: > On 21 March 2011 21:08, Alex Deucher <alexdeucher@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
