Re: GGI, EGCS/PGCC, Kernel source

Jes Degn Soerensen (jds@kom.auc.dk)
23 Feb 1998 19:59:23 +0100


>>>>> "Ard" == Ard van Breemen <ard@cstmel.hobby.nl> writes:

Ard> On 23 Feb 1998, Jes Degn Soerensen wrote: <snip>
Ard> Hmmm, is there somebody working on TIGA? I hate to switch to SCO,
Ard> even to only try out there X-server. As TIGA is very
Ard> computer-independent joined forces could be very nice.

I hacked a TIGA console for an old Amiga TIGA board a couple of years
ago, but I put the project on hold since I have a ton of other
projects to work on and the number of potential users is not very
high.

There are even sources for an X server available (X11R5 I think,
written by Paul Mackerras if I remember correctly), but I never got
around to take a closer look at this.

>> screen-mode switching in the kernel, which is necessary for the
>> framebuffer devices. I can't see a lot of other graphics related
>> issues that needs to go into the kernel.
Ard> As for tiga, I can only see some communications go in the
Ard> Kernel. Probably the whole X-server could run on the TIGA board
Ard> :). If it really is that bad the communication could be written
Ard> as a network device... But then again it is not necessary except
Ard> that polling is not that nice for a board that is only accessed
Ard> through a single I/O port... Every us counts in that case...

For TIGA it is quite easy, you just map the registers to user-space
(or use the x86 inb() outb() ones) and let the user space part of the
X-server talk to the code running on the board. This can be done
fairly simple by creating a kind of `command queue' on the board and
let the 340x0 code poll this queue for things to do. This way you
shouldn't need a lot of interrupt handling in the kernel.

Jes

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu