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
