On Tue, May 31, 2016 at 6:22 PM, Ben Hutchings <b...@decadent.org.uk> wrote: > On Tue, 2016-05-31 at 17:34 +0200, Mathieu Malaterre wrote: >> On Mon, May 30, 2016 at 9:50 PM, Ben Hutchings <b...@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.
Ok. Too bad offb is built into the kernel (not as module): $ grep FB_OF /boot/config-4.5.0-2-powerpc CONFIG_FB_OF=y I'll see if I can reuse any of the existing hack [*] for my Mac Mini G4. [*] $ grep -i hack drivers/video/fbdev/offb.c /* Supported palette hacks */ /* Definitions used by the Avivo palette hack */ static void offb_init_palette_hacks(struct fb_info *info, struct device_node *dp, offb_init_palette_hacks(info, dp, name, address); /* Hack for when BootX is passing us */ * a display (just not the palette hacks).