> Stefan> On 24 Feb 1998, Jes Degn Soerensen wrote:
> Will you use user space access to video registers when these can be
> memory mapped and kernel access for boards that do only support the
> old brain-damaged port IO? Or will you do all access to the video
> boards' registers using ioctls in kernel space? (for me it doesn't
> make a difference whether kernel space is something compiled into the
> kernel statically or if it is a loadable module - it is all kernel
> context).
We can do both, and the drivers simply uses what the card can handle
securly.
> Stefan> Living in kernel space is also our drivers, and just like any
> Stefan> other system they can be compiled in or loaded as a
> Stefan> module. The drivers knows about their hardware, and exports
> Stefan> some ioctl calls, some general, some specific to the
> Stefan> hardwarde, in order to let userland change modes, use
> Stefan> acceleration etc.
>
> Acceleration in kernel space using ioctls, sorry but no thank you. If
> you want performance you still need to let the user-space applications
> such as X and svgalib type things (is that what ggilib is?) access the
> hardware directly. If it requires apps to be suid root in order to
> access IO-ports then it is just the price you have to pay IMHO.
Ok, I will rephrase and comment. You _have_ to use an ioctl if you want to
go from userspace to kernelspace, and yes, that is slow. That's why we are
using a buffer where we can store multiple acceleration commands and do
several at once.
LibGGI is a small library that takes care of a lot of this. It's API
allows to set various modes etc, but it does not contain anything that
will draw for you, other libraries will be responsible for that.
Was that clearer?
> Well I didn't look closely at the X server performance comparisons,
> and frankly I need a usable console before I will even consider X
> performance.
Sure, but people asked me about performance, and that was the only one I
had available. Trust me, with the exception of bugs in some of the
drivers, the consoles are highly usuable. Don't take my word for it,
_try_ GGI yourself.
> As to those slides, I still don't see a clear explanation as to what
> actually goes into the kernel and what does not. I asume a lot of it
> is hidden in this `graphics special file' ? The closest thing I can
> find is a reference to some `accelleration ring buffer' which I asume
> is to communicate with acceleration inside the kernel?
Going to forward this question to someone who is more of an acceleration
expert than I am. But we do try to add as little as we can to the kernel.
> Stefan> So, please, come and have a look for yourself. If you feel
> Stefan> that we are doing something good, then please tell us and
> Stefan> linux-kernel so. If you feel something should be done
> Stefan> otherwise we will listen to that too.
>
> I've been there now, any well maybe I didn't look close enough, but I
> didn't find a lot of information that convinced me that GGI is the
> ultimate solution in the end. All the things about input devices etc.,
Yes, well, I am sorry if I am not good enough to convince you. You will
just have to wait and see then.
> >> I do agree entirely with Alan when he says that bits from both
> >> camps will be the right solution in the end.
>
> Stefan> Ok, what specific bits?
>
> I belive that having video-mode switching in the kernel is a good
> thing, and it is mandatory for some architectures. Your driver
> architecture which splits the handling of the seperate chips is quite
> similar to what I would like to do and you have a lot more low-level
> driver code than we have for obvious reasons.
>
> Having some sort of standard user space library to handle video acces
> is also a nice idea, and I don't mind having the X server built on top
> of this. However, I still belive that all the acceleration details has
> to go into the user space library and not the kernel.
>
> However, how are you going to deal with architectures that do not have
> VGA-style text-modes for the console and how will you deal with weido
> devices such as TIGA boards?
If VGA-style doesn't exist, then of course we can't use it, that should be
pretty obvious. That don't mean that a textmode can be written up for the
driver with a little bit of care. It's pretty much up to the author of the
driver, and to the hardware, what will suit best. That might be opeing a
800x600 screen and blit the fonts (just an example, don't flame me). We
are trying to be open.
I don't know enough of TIGA boards myself to comment, though I know it has
been discussed on the GGI mailing list. Obscure hardware is being dealt
with.
Join the mailinglist and ask our wizards yourself should you not believe
me.
-Stefan
/-----------------------------------------------------------------------------\
| Stefan Mars |Student, Applied physics & Electrical engineering |
| Bjoernkaerrsgatan 15B:30 |Linkoping Institute of Technology |
| S-584 36 Linkoping | |
| Sweden |Email: mars@lysator.liu.se Phone: +46 (0)13175384 |
|-----------------------------------------------------------------------------|
| Maintainer of The THX Home Cinema Buyers Guide, located at |
| http://www.lysator.liu.se/%7Emars/thxguide.html |
\--------------------- PGP key available through finger ----------------------/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu