Re: [Linux-fbdev-users] (2.6.9-rc4|2.6.9|2.6.10-rc1) black cursor on console [ppc platform]
On Tue, 2004-10-26 at 10:36, Geert Uytterhoeven wrote:
> On Tue, 26 Oct 2004, Antonino A. Daplas wrote:
> > On Tuesday 26 October 2004 15:34, Guido Guenther wrote:
> > > On Tue, Oct 26, 2004 at 04:09:44AM +0800, Antonino A. Daplas wrote:
> > > > On Tuesday 26 October 2004 02:49, Elimar Riesebieter wrote:
> > > > > On Mon, 25 Oct 2004 the mental interface of
> > > > Can you try booting with video=radeonfb:noaccel?
> > >
> > > I'm not sure if this has already been mentionend outside of the debian-ppc
> > > list: this also happens with at least rivafb and offb too.
> > This is the first time I knew about this problem. Note that gpm
> > predominantly uses the TIOCLINUX ioctl which mainly manipulates the
> > screen_buffer.
> > So each time the mouse is moved, gpm sends an ioctl that complements or
> > reverses the attributes of the character underneath the mouse cursor, then
> > it sends a putc command (telling the console to repaint the character). It does
> > not use the fbcon cursor API.
> > In all drivers I tested in the i386, gpm seems towork correctly.
> > I can't really much help in this area except for someone with a PPC machine
> > to debug the TIOCLINUX ioctl and complement_pos in drivers/char/vt.c and the
> > selection code in drivers/char/selection.c.
> Just a guess: has anyone recently introduced an endianness-bug somewhere in the
> selection code?
The other common problem is that "char" is unsigned by
default on PowerPC.
**sigh** None of this is necessary. I've used PowerPC in
little-endian mode before, and it works great. Having a
motherboard that does a 64-bit byte swap is helpful for
PCI IO, but certainly not required. On a Mac, you'd simply
need to anti-munge the IO addresses in addition to the
byte swapping that's already done for PCI IO. Also, the
page table entry code needs to order the bits differently,
and loading the MSR may require an extra instruction.