On Tue, 2016-05-31 at 17:34 +0200, Mathieu Malaterre wrote: > On Mon, May 30, 2016 at 9:50 PM, Ben Hutchings <ben@decadent.org.uk> wrote: > > Control: reassign src:linux 4.5.4-1 > > Control: tag -1 help > > > > On Mon, 2016-05-30 at 18:42 +0200, Mathieu Malaterre wrote: > > > Package: linux-image-4.5.0-2-powerpc > > > Version: 4.5.4-1 > > > > > > During Debian installation the background color is inverted on PPC system. > > > At least on my Mac Mini G4, the default background color shows up as red > > > from begining to start (only the last screen turn blue). > > > > > > Looking at the module loaded during the installation I can see radeonfb, > > > which I suspect is the one responsible for handling of `/dev/fb0`. > > > > > > After installation I tried reproducing this color inversion without any > > > luck so far. > > > > > > It is non-trivial to `rmmod radeon`, so instead I used (and rebooted): > > > > > > $ cat /etc/modprobe.d/radeon.conf > > > blacklist radeon > > > > > > However upon reboot `/dev/fb0` is already setup. > > > > Of course, because there is no character-based display mode on Power > > Macs (in general). > > > > > But neither radeonfb nor > > > radeon module seems to be loaded (using lsmod) but lspci output is rather > > > confusing [*]. > > > > lspci lists all kernel modules that match a particular PCI device's ID, > > and separately whether any kernel driver is currently bound to the > > device. > > > > > I can also see: > > > > > > $ cat /proc/fb > > > 0 OFfb ATY,RockHo > > > > As I would expect, the generic Open Firmware framebuffer driver is > > behind /dev/fb0. If a hardware-specific driver is loaded, that will > > take over from it. > > Thank you ! Ok now I understand. d-i tried to modprobe `radeonfb` but > fails since framebuffer is already taken by Open Firmare, as can be > seen in the dmesg log: [...] That's *not* what I thought was happening. I was expecting radeonfb to do something like this (in the radeon DRM driver): https://sources.debian.net/src/linux/4.5.4-1/drivers/gpu/drm/radeon/radeon_drv.c/?hl=336#L336 and maybe to query offb about the existing framebuffer properties first. So the problem is simpler: offb gets the palette or pixel format wrong and loading radeonfb afterwards doesn't help because it doesn't take over from offb. On the installed system, the radeon driver is auto-loaded (although it will still fail initialisation if the firmware is missing, except for old ATI chips). It can take over from offb and (presumably) gets the colours right. Ben. -- Ben Hutchings Any sufficiently advanced bug is indistinguishable from a feature.
Attachment:
signature.asc
Description: This is a digitally signed message part