Bug#825840: linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color
On Tue, May 31, 2016 at 6:22 PM, Ben Hutchings <ben@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 <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.
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).
Reply to: