Re: Boot-time script to disable DFB's HW acceleration
Sven Luther wrote:
ok, so i suppose checking if /sys/bus/pci/drivers/<broken fbdev device>
Yep, in the general case, it should be possible to have multiple graphic
cards, and the broken one not being the one used for booting d-i.
anyway, even if DFB's hw accel is disabled because a broken video card,
even if it's not the one used for the install, is detected, nothing bad
should happen..
Also, of interest is :
/sys/class/graphics/fb0, which has a device/driver symlink to the above path
you suggest, but i don't know how to find the radeonfb driver name information
from this one, which sucks.
i see from here or dmesg output we can also get the screen width and
height: this could be useful to make the frontend match the fbdev
resolution.
if something like dfb/screen_width and dfb/screen_height could be stored
at this point, later the GTK FE could read those variables and
consequently open a window that has correct dimensions, and also the top
banner could be resized as needed.
exist is enough to tell if HW acceleration has to be disabled.
Below is the same script reworked after your and Geert Stappers's
corrections.
The user, to manually disable DFB HW acceleration, should boot with
something like "install NO_DFB_ACCELERATION=TRUE" and this should be
documented in the d-i manual and/or in the help screen that you see when
you press F2 at boot time.
Yeah, altough i prefer the lower-case new option format thingy, but maybe they
are reserved for debconf variables ? dfb/no_accel=true ? Do we have access to
debconf already at this early stage ?
dfb/no_accel=true is ok for me, ususally the directfbrc file is parsed
just after debconf is started (i don't remember the service index right
now..), so it must be setup before cdebconf loads the GTK frontend.
Where this piece of code should be collocated? inside a new "Sxx.sh"
script or should be better appended to
/lib/debian-installer.d/S35framebuffer-linux or some other already
existing script?
Not sure, it has to run early enough (before gtkdi is launched) and late
enough (after the framebuffer drivers have been loaded.
Maybe adding ti to S35framebuffer-linux is a good thing.
Who can state if that's a good choice?
Note that the list of bad fbdev deviced is hardcoded inside this script:
is this a good idea? but i have no idea of where else those could be
listed..
It should be a preseedable debconf value maybe, not sure, see my above
comment, dfb/bad_fbdevs="nvidiafb atyfb" would be a good idea. Maybe we could
reverse the script and whitelist the known good graphic cards though, with :
dfb/good_fbdevs="radeonfb vesafb" ?
i think the blacklist option is the best choice if we want to support
testing of DFB accelerated modules among debian users.
Otherwise we could simply disable DFB's hw acceleration by adding
"no-hardware" to etc/directfbrc from rootskel-gtk package, but this
wouldn't allow a widespread testing of DFB's accelerated funcionalities.
ciao
Attilio
Reply to: