> Not restricting it to /dev/keyboard or such might introduce
> security problems though, and most of all, I consider that "normal"
> applications shouldn't be using /dev/keyboard directly.
What do you call a normal application ? Midnight Commander,
editors using Control-Return or Alt-Tab should not be normal ?
Concerning security, you can use /dev/tty for everything
you want, you are the owner. Some are even downloading Mbytes with
XYZ-modem or minicom. The shell or your application interpret
it as it wants.
> > Midnight Commander uses the mouse, and a lot of editors could
> > also if there was one simple system, available in text and graphic
> > mode (transparently). The VT1200 system is simple enought to
> > manage text-mode menus with mouse on a 9600 baud line.
>
> What about "X for text-mode"? There already exists a widget system for
> curses, though.
Did not know this one. How does it interract with gpm ? Can you
use "gpm -R" and read the mouse information (converted to
MouseSystem protocol) in "/dev/gpmdata" while in console mode ?
Does that work transparently in an Xterm, i.e. the mouse events
goes to gpm, then to X, then converted back to MouseSystem protocol
to be send to curses ?
> > Yes, but you reach the printer which is "attached", i.e. near the
> > user keyboard, even with a 3 level rlogin through a Vax.
>
> see security issues. if you want access to the printer, write: cat|lp, or
> something similar.
If I am very far away from the host computer, in a wide network,
that is more "cat | lpr | fedex" (Federal Express).
I would like to say to the computer I am talking to: print this file
on the printer attached (by the hardware printer port) to my PC -
even if this printer has no network name defined on the distant
network.
For me, there is not a big difference between the keyboard, the
screen and the printer: they all three are local. The operating
system already give complete access to keyboard and screen - if
not disabled, data received for printer can be piped to /dev/lp,
managed in the same way as /dev/tty* <-> /dev/tty, protected with
standard chmod.
> > using differences between Linux console and VT100 standard. There
> > is still legal problems.
> > It is indeed not related to your proposed system.
>
> heavily unrelated. I cannot reply to most of your message while keeping
> in mind our project, simply because it's not related. So I'd like to keep
> the thing to a minimum and then you'll do all the clever things you wish
> on the top of it.
I just wanted to describe the current situation. If you want
to change some things, please try to simplify this system...
> > A so old story, I didn't see the very first beginning, but so much
> > cleanning has to be done there - years of work, just to be able to
> > cleanly manage the ESC key of PCs !
> > So for me, when you say "let's add another layer", I become quite
> > nervous.
>
> For normal applications, it wouldn't even matter, it would just cut some
> duplicate stuff out of svgalib/X/gpm/dosemu and friends, and make them a
> little less dangerous as well.
But svgalib/X/gpm/dosemu would use your protocol after - take care
of a Xterm running dosemu - where the user want to X cut&paste.
> > Note: I did not received any linux-kernel E-mail for two days...
>
> i've received like 250 of them...
I will have something to do tomorrow !
Bye,
Etienne.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu