bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug#185450: missing virtual terminal ioctl's


From: Robert Millan
Subject: Re: Bug#185450: missing virtual terminal ioctl's
Date: Thu, 20 Mar 2003 13:02:05 +0100
User-agent: Mutt/1.5.3i

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]