On Thu, Mar 20, 2003 at 02:40:02AM +0100, Marcus Brinkmann wrote:
> On Thu, Mar 20, 2003 at 01:35:30AM +0100, Robert Millan wrote:
> >
> > and the Xserver is also accessing VGA and keyboard directly? looks like
> > an unnecessary code duplication to me.
>
> What code do you think is duplicated? open ("/dev/mem") and mmap () or
> vgamem[index] = value?
I don't know vga, so i was talking mostly for the keyboard. (on vga, see below)
> A framebuffer would be interesting.
uhm.. a framebuffer is a matrix-like proxy, right?
> Apart from that, we already have the
> right separation. If you disagree you should consider the disadvantages of
> indirect access to, for example, the keyboard scan codes. You would want
> all the features that are already in X, like switching between input maps.
there are some advantages, like the different kinds of keyboards out there.
if you have a serial or a stowaway keyboard instead of a PC one, you'll just
need to change /dev/keyboard
as for the key mapping i don't think it belongs there, non-priviledged users
should be able to map their keyboard somewhere else (do the console server
and X permit this?)
> Now, you can say that all projects need these features, and a common server
> with a nice interface (which suddenly becomes much more complicated than a
> ioctl for leds) would benefit them all. But what projects could that be?
> The console, XFree86, and what? Fresco? There it pretty much ends.
and all svgalib-based projects: lxdoom, bochs.
but if there are 2 projects sharing a resource that need coordination,
someone should be coordinating them. on the keyboard this is simple and
on vga we might want a lower-level proxy to allow direct rendering.
> You are talking about the status quo. But the status quo is nothing to be
> concerned about, nor is it a good example how it should be.
it is when some components we want are already implemented..
> However, the console client mouse driver could provide /dev/mouse.
there's a translator providing /dev/mouse already, what is wrong with it?
> > if a translator for each of screen, keyboard and mouse monopolises its
> > access, then it's easy to disallow more than one client to use it at once,
> > and coordinate them.
>
> That's easier said than done. Maybe you should think a bit more about it.
> Problems pop up all along the way from having the idea to putting it into an
> implementation. Some pointers to potential problems are in the console
> threads I had with Roland.
i'll have a look
> Performance problems in general. You can not abstract the hardware in a
> general interface and still have direct rendering. Unless you are only
> talking about wrapping direct hardware access into a wrapper for convenient
> resource management. Which would then only be syntactically different from
> what we decided to do.
i haven't seen any decision, you mean the cooperative protocol for console
switching?
then it's not only syntacticaly different. Xfree86 and others need root
permissions to access hardware, with a direct hardware access wrapper they'd
just need to somehow identify themselves to the wrapper. (say, user/group
vga-screen has write perms in /dev/vga-screen)
> In some cases you want to access the hardware directly for maximum performance.
> For example video streaming.
aha. then you're completely right that a monopolising matrix-like proxy for
VGA is not a good thing.
> I can only recommend to reread the console discussion, and then if you have
> a good idea (like the one above), start to actually think through how you
> would implement it. As soon as you start to write down what components you
> want, and how they interact, you can start to think about border and race
> conditions, and what happens if you start to include desirable features.
>
> You can not discuss the problems of an idea like this based on one or two
> sentences describing the idea. You have to work on it at a much finer detail.
indeed.
> >From my experiments, some details of the console server/client designs were
> only clear to me after a couple of months of starting the actual
> implementation. I wouldn't expect it to be different for other similar
> ideas. Only so much: The plan as I have outlined it is a clear and
> restricted project: The cooperative protocol for console switching is easy
> to design and implement, and we know that it will do well. Whereas what you
> hinted at is a full scale separate project more like kgi, and it's not at
> all clear what is the correct approach to that, or how it can be put into
> something usable and useful. In other words: If you are interested in the
> hacking, then go ahead. But if that is something you want to do, you can
> put < 0.1 % of the time that would go into that and do the cooperative
> console switching as a warming up exercise.
I don't know the console and realy have no idea on how to dessign that
cooperative protocol. i think i'm not the indicate one to implement this
(besides that i have a different idea to replace VT_ACTIVATE-like stuff).
since this is suposed to be a simple task if you know well the console,
i think it'd be fairly easy for you to implement it (then we'll have a
working Xfree86 in a while)
--
Robert Millan
make: *** No rule to make target `war'. Stop.
Another world is possible - Just say no to genocide
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
