What about a kernel module?

2003-10-08 Thread Raymond Jennings
I'd like to suggest that you implement device-specific code as a kernel module. Have something like /dev/videocard or /dev/framebuffer, and a kernel module to control it Cause reads and writes to access video memory, and have IOCTL's for everything else (including sync frequencies, video modes

Re: What about a kernel module?

2003-10-08 Thread Ian Romanick
Raymond Jennings wrote: I'd like to suggest that you implement device-specific code as a kernel module. This has been discussed to death. XFree86 is portable to systems where we can't just willy-nilly add kernel modules. With few exceptions, such as to implement hardware 3D, this is right out

RE: What about a kernel module?

2003-10-08 Thread Daniel Chemko
>Have something like /dev/videocard or /dev/framebuffer, and a kernel module >to control it /dev/fb does exist and is more or less used for your purposes. There is also a frame buffer X Server module as well. I am not sure if it work on mainstream Xfree, but I do know that kdrive has had it for

Re: What about a kernel module?

2003-10-08 Thread Tim Roberts
On Wed, 08 Oct 2003 19:12:56 +, Raymond Jennings wrote: > >I'd like to suggest that you implement device-specific code as a kernel >module. > >Have something like /dev/videocard or /dev/framebuffer, and a kernel module >to control it > >Cause reads and writes to access video memory, and have

Re: What about a kernel module?

2003-10-08 Thread Alan Coopersmith
Raymond Jennings wrote: I'd like to suggest that you implement device-specific code as a kernel module. For which kernel? XFree86 runs on Linux, FreeBSD, NetBSD, OpenBSD, Solaris, Windows (Cygwin), OS/2, and a few more platforms, each with a different kernel architecture (and in Linux's case, man

Re: What about a kernel module?

2003-10-08 Thread Juliusz Chroboczek
>> I'd like to suggest that you implement device-specific code as a kernel >> module. Well, that won't happen; we already have working portable driver code in userspace, and there's no chance we'll port that to the Linux kernel. On the other hand, I do think that we'll end up using more kernel-s

Re: What about a kernel module?

2003-10-08 Thread Juliusz Chroboczek
AC> (Of course, we do this somewhat on Solaris/sparc, Do you document the interface ? Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel

Re: What about a kernel module?

2003-10-08 Thread David Dawes
On Wed, Oct 08, 2003 at 01:05:23PM -0700, Tim Roberts wrote: >XFree86 runs quite well >in many non-Linux environments today. Not to mention that Linux was only the third or fourth platform that XFree86 ran on, with several SYSV versions and 386BSD pre-dating the Linux port :-). As to the origina

Re: What about a kernel module?

2003-10-09 Thread Alan Coopersmith
Juliusz Chroboczek wrote: AC> (Of course, we do this somewhat on Solaris/sparc, Do you document the interface ? Partially - the generic interfaces all frame buffer drivers support are documented in the fbio(7) man page (available online at http://docs.sun.com/ ) and some frame buffer drivers docum

Re: What about a kernel module?

2003-10-09 Thread Emmanuel ALLAUD
Juliusz Chroboczek wrote: I'd like to suggest that you implement device-specific code as a kernel module. Well, that won't happen; we already have working portable driver code in userspace, and there's no chance we'll port that to the Linux kernel. On the other hand, I do think that we'll

Re: What about a kernel module?

2003-10-09 Thread Mark Vojkovich
On Wed, 8 Oct 2003, Emmanuel ALLAUD wrote: > Juliusz Chroboczek wrote: > > >>>I'd like to suggest that you implement device-specific code as a kernel > >>>module. > >>> > >>> > > > >Well, that won't happen; we already have working portable driver code > >in userspace, and there's no chance

Re: What about a kernel module?

2003-10-10 Thread Emmanuel ALLAUD
Mark Vojkovich wrote: On Wed, 8 Oct 2003, Emmanuel ALLAUD wrote: Juliusz Chroboczek wrote: I'd like to suggest that you implement device-specific code as a kernel module. Well, that won't happen; we already have working portable driver code in userspace, and there's no