[lkml]   [1998]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: kill -9 <pid of X>
>>>>> "Albert" == Albert D Cahalan <> writes:

>>> Huh. OK, so all accels now are to be done with driver-specific
>>> ioctls?
>> No in user space

Albert> So why give userspace a framebuffer device at all? The X
Albert> server will need to bang the raw hardware anyway. You could
Albert> have the kernel code just do the /dev/tty* and /dev/vcs*
Albert> devices, without the useless framebuffer ones. Since X needs
Albert> privilege to access the accelerator anyway, it might as well
Albert> just open /dev/mem.

Because you can do other things than running X-servers on a frame
buffer device and because it allows you to use the frame buffer device
to handle things like mode switching.

Albert> That would be less kernel bloat, even for 680x0 systems with a
Albert> console! Really, the framebuffer devices don't give us
Albert> anything useful.

You are obviously missing the whole point of this, or would you mind
sending me a patch which will allow me to run the console on a Sparc,
most m68k boxes & many MIPS, ARM & PPC boxes without setting up the
video resources in the kernel? /dev/fb gives us a standard way of
accessing video cards' memory from user space so we don't need to
reinvent the wheel.

>> When you want to have accel control in user space, you tell fbdev
>> and it wont use acceleration for the console until the user space
>> program finishes with it.

Albert> That isn't safe. You can't expect to access video memory at
Albert> all while the X server is running the accelerator. You may
Albert> crash the card.

fbdev deals with this, and its only a certain number of cards that are

Albert> You also need to get into a simple video mode before X starts,
Albert> so that the X server knows the video mode. You can't do that
Albert> with VESA.

Or let the X server use the mode information from /dev/fb and use
/dev/fb to set the video modes for it.

Albert> This system just isn't going to cover all PC hardware with
Albert> full acceleration support in userspace. I'm sure it works just
Albert> great on your 680x0 machine, but Linux runs on PC hardware
Albert> too.

Look at the code and features before commenting please.

>> We did not do that on purpose, ioctl == context switch and we don't
>> want that.

Albert> You don't want it, but I do. Access to the X server is alreay
Albert> worse than a context switch -- if you are serious, get rid of
Albert> that.

Oh, you didn't follow the long thread we had about this on
linux-kernel some month ago either?

Albert> The context switches are cheap if you queue a large number of
Albert> requests. (and cheap if you don't have large numbers) It is a
Albert> very small price to pay for a reliable system with decent
Albert> performance.

No its not - and most of the time you can only queue a very low number
of requests because you want to sync the blitter before starting new


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:44    [W:0.054 / U:20.616 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site