First directfb is a userspace library that allow to access (/drm/card0 or /dev/fb0) and input in same way like xorg stack. directfb != frambuffer (as common name for framebuffer ;) This library have nothing to do with plymouth.
Currently there are 3 ways to have decent GUI: 1. Xorg 2. directfb 3. wayland On top of these, some GUI framewrok like GTK or QT can be build. Since Xorg is widely used on omv environment, and wayland is gettin more into shape, there is NO need to maintain yet another userspace library which has never any use and will have any use at all. I feel exhausted of explaining same thing over and over. 2014-10-08 21:18 GMT+02:00 Colin Close <[email protected]>: > On Wednesday 08 Oct 2014 01:18:16 Tomasz Gajc wrote: > > But how? > > Here we comes to a place where > > it is needed to explain how things works in Unix world. > > I had this feeling this is quite obvious, but finally found I've made a > > mistake. > > > > Nowadays graphics subsystem is handled by KMS/DRM, and yes frame buffer > is > > managed by simplefb driver which creates /dev/fb0 as a fallback device > for > > drm/card0. There is no psychically, at least known to me, possibility to > > use at the same time DRM and fb0 related to one graphic card. Simply when > > you are running x11 server or wayland you can not use directfb and vice > > versa, so having support for directfb in gtk/qt is just an overkill and > > waste of time and resources. > > > > Really it is time to ease life and stop supporting things that are meant > > not to work because of above. > > > > Wysłano z Samsung Grand Neo Orange Polskak > > I am not sure that I have been properly understood either. I think I > understand your reasoning, surely though I can still pass NOKMS or > NOMODESET > to the kernel to avoid loading the DRM. Plymouth will still deal with this > by > reverting to text mode. If I understand the requirement the fbdevice is not > required for any gtk or QT applications and so you can drop those > dependencies > hence it seems a possible solution to me. It is true that the library would > need maintenance but those who wish to keep it are quite capable of that. > So > is there a problem that I have overlooked or not understood. The only > thing > external to the library I can think of is a udev entry but I guess that > comes > with the kernel which is maintained separately. The only difference between > having it in main and having it in contrib then is the fact that it gets > installed when the os is installed which means it's instantly available to > those who need to use it. > Perhaps there is something I have missed. > Best > Colin > > Colin Close > QA Team > > > > _______________________________________________ > OM-Cooker mailing list > [email protected] > http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org >
_______________________________________________ OM-Cooker mailing list [email protected] http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
