linuxconsole-dev

Diff to show my work

[James S. <jsi...@ac...>]

Hi everyone!!

  Well I have the patch attached what I have done. It bzip2ed and its 76K.
Unzipped it 536K so you can see it is a massive rewrite. I still have some
cleanup to do yet and some early testing.

Completed:

 Removed dependency on currcon. Now it uses vc_data. 
 
 Removed struct vc. Not needed.
 
 Changed what vt_struct and vc_data do. Now vt_struct represents a real VT
 and vc_data represents each VC. 

 Each vt_struct has a VC pool since you see /dev/tty0 to /dev/tty64 but
 each /dev/tty could belong to some head we don't know about. So the 0-64
 to VC pool/VT mapping code had to worked out. 

TODO:

 Fix con_open. Right now the console system dynamically allocates each VC.
 I have to figure away to find which VT each tty belongs to when con_open
 is called.

 Finish the VT switching code. 
 
 Figure out how to have each head be able to be blanked indepedently of
 each other.

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

entering new code in CVS

[James S. <jsi...@ac...>]

I have most of the code done for the new console system. It still has a
few cleanups to do. The question is should I place it in CVS or wait until
its somewhat stable. I can place it on the web for people to see instead
for now or post a diff. What do you think?

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: Supporting multiple keyboard

[James S. <jsi...@ac...>]

> What about the non-XFree based servers out there? MetroX, AcceleratedX, etc?
> You don't want to tell me you want to break them with 2.6, do you?

I would not make such changes at the very start. The broken API should be 
kept until apps don't need it anymore. I will let these companies know of
the changes. Two year from now, to be on the safe side, X servers etc will
be using fbdev and the input layer. Especially if they want to support
multihead systems. So in time the need for this out dated API will go away
:) Just like a.out support. After I'm done with the console project I will
work on the porting every single card supported by XFree86 to the fbdev
layer.

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: Supporting multiple keyboard

[Steffen S. <s.s...@ph...>]

James Simmons wrote:
 
> > On another note, I think you should definately not change the semantics of
> > the console switching behaviour. This is used by other operating systems too,
> > so if you break this, you will make Linux incompatible with quite some
> > applications. (See the VT-switch handling code in the X server, as a reference).
> 
> We will keep it until the end of the developement cycle for 2.5.X. Hopefully
> the X servers will be updated by then.

What about the non-XFree based servers out there? MetroX, AcceleratedX, etc?
You don't want to tell me you want to break them with 2.6, do you?

> One it's a bad design.

You can have a better, extendable design thats compatible with it. See
KGI-0.9 for reference.

> Two linux is moving in a different direction than other UNIX OSes.

If breaking compatibility with other UNIX environments is a result of
this move, I will quickly loose interest in Linux.

> It's would be a mess to support the standard method and multihead at
> the same time.

That's not true. KGI does allow for multihead and the 'standard' method
at the same time, and I would not call it a mess. This code is not
easy to understand, yes, but that's inherent to the subject, not a
particular issue of the approach.

If XFree would not try to boot every graphics card it finds messing with
PCI configuration space etc, this could be demonstrated IRL.

> Their is already code in the X servers that is linux specific.

I don't question that.

> Adding the input interface will add more. Using the input layer works
> more toward how X is designed.

Sure, that's my opinion too.

> X also see every device including the keyboard as a input device.
> I have been looking at the X server design to work in the input stuff.

But I am not talking about the input stuff here. I am talking about changing
the semantics of the console switching protocol that would break all Xservers
out there for Linux, not to speak of other applications.

I had taken out the console switching stuff when developing early KGI versions,
and I can only request you to think well before you make this move.

			Steffen

_______________________________________________________________________________
Steffen Seeger                              mailto:se...@ph...

Re: Supporting multiple keyboard

[Steffen S. <s.s...@ph...>]

Prarit wrote:
> 
> > (See the VT-switch handling code in the X server, as a reference).
> 
> Hi Steffen, could you point me to where this code might be in X?
> I can't seem to find it :(
> 
> Thanks,
> 
> P.

xc/programs/Xserver/xfree86/os-support/VTsw_usl.c (4.0)

The point I am making is that by changing this, you will break not only
all XFree-4.0 binaries out there, but also all the other (commercial)
servers.

			Steffen

_______________________________________________________________________________
Steffen Seeger                              mailto:se...@ph...

Re: Supporting multiple keyboard

[James S. <jsi...@ac...>]

> > I understand it now. What I was wondering was is thier a switch between
> > data goingt to eventX or to the VT for the keyboard. If someone opens a
> > eventX that is a keybaord and belongs to a VT will the data automaticallly
> > flow to eventX instead of the console system.
> 
> The data always flows to both. Input.c is multiplexing it.

Hum?? This could be the way to handle the security problems with /dev/eventX 
and /dev/tty. On implict opening of /dev/event the data flows to the event
interface instead of to /dev/tty. Otherwise all data flows to /dev/tty. If
you need to send key events to the console while having /dev/event open 
then a program could send the data to /dev/tty directly. 

> Uh-huh. This means we won't be able to do what we can do now - have a
> VGA and a MDA adapters & displays and one keyboard and have some
> consoles on the first and some on the other.

You still can. Its just userland will handle this. A daemon could easily 
be created to handle this. The handling of odd ball systems with X amount
of keyboards and Y amount of video display systems where X != Y will get
very complex and very large. We are better off letting a userland app
handle this.

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: Supporting multiple keyboard

[Vojtech P. <vo...@su...>]

On Sat, Jun 10, 2000 at 09:42:20AM -0400, James Simmons wrote:

> > If you plug in a PS/2 keyboard (and the i8042 kbd port is active,
> > there is going to be some changes to better support hot-plugging PS/2
> > keyboards and mice) then the atkbd.c module initializes it and registers
> > it with the input subsystem. evdev.c gets offered the input device, and
> > accepts it, because it accepts any input device. It creates
> > /dev/input/event0. keyboard.c doesn't get offered the device, because
> > it's not compiled in when ve don't have VT's.
> 
> I understand it now. What I was wondering was is thier a switch between
> data goingt to eventX or to the VT for the keyboard. If someone opens a
> eventX that is a keybaord and belongs to a VT will the data automaticallly
> flow to eventX instead of the console system.

The data always flows to both. Input.c is multiplexing it.

> > Btw, can this approach handle two displays with one keyboard?
> 
> I'm going to take heat for this but no. The reason being is linus is a
> strict about what things are defined as. Evstack attempted to bend the
> rules to what a tty was with multi keyboards and multiple displays. Linus
> did not like it. What will be accepted is a tty is one display and one
> keyboard. It also makes the design much simpler. Now I would like to see
> such features as well. So it accomplish this we need to make userland
> flexiable to be able to do this.

Uh-huh. This means we won't be able to do what we can do now - have a
VGA and a MDA adapters & displays and one keyboard and have some
consoles on the first and some on the other.

-- 
Vojtech Pavlik
SuSE Labs

Re: Supporting multiple keyboard

[James S. <jsi...@ac...>]

> The question is which software is to blame for the bug. The kernel for not
> using a rock-solid locking mechanism? The application(s) for having to
> implement independent device driver instances touching the same hardwae
> in preemptive code sections?

It was needed for it time. Now things are evolving in another direction so 
things will be done right in time.
 
> Even if they handle switches 'correctly' from a software-theoretical point
> of view they could get scheduled in the middle of setting up the hardware.

Right. I have patches avaliable for fbdev and the console system to fix
this which I will place in cvs soon :)

> Scheduling or suspending (at user's request) applications using DRI is not,
> and I wonder how the DRI developers intend to fix that cleanly.

Userland locks. If you get scheduled away no other process doesn't get
access to the video hardware. This is of course means you cross your
fingers and hope the apps obey the locks. In the DRI approach the OpenGL 
library handles all this. In other words the attitude is use the OpenGL
library supplied by DRI. Don't do your own thing :(

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: Supporting multiple keyboard

[James S. <jsi...@ac...>]

> If you plug in a PS/2 keyboard (and the i8042 kbd port is active,
> there is going to be some changes to better support hot-plugging PS/2
> keyboards and mice) then the atkbd.c module initializes it and registers
> it with the input subsystem. evdev.c gets offered the input device, and
> accepts it, because it accepts any input device. It creates
> /dev/input/event0. keyboard.c doesn't get offered the device, because
> it's not compiled in when ve don't have VT's.

I understand it now. What I was wondering was is thier a switch between
data goingt to eventX or to the VT for the keyboard. If someone opens a
eventX that is a keybaord and belongs to a VT will the data automaticallly
flow to eventX instead of the console system.

> >   I'm using struct vt_struct to represent each physical VT (a display and
> > a physical keyboard).
> 
> Btw, can this approach handle two displays with one keyboard?

I'm going to take heat for this but no. The reason being is linus is a
strict about what things are defined as. Evstack attempted to bend the
rules to what a tty was with multi keyboards and multiple displays. Linus
did not like it. What will be accepted is a tty is one display and one
keyboard. It also makes the design much simpler. Now I would like to see
such features as well. So it accomplish this we need to make userland
flexiable to be able to do this.

> Maybe it'd be better to use struct input_handle *handle as the keyboard
> identifier in the vt_struct.

Okay.

> Searching is not nice. A better way would be to set up the handle->private
> pointer to point to the VT struct - this way you don't have to search
> for anything.

We might have to do this. 

> Well, it needs to be rethought what's is going to be in struct
> vt_struct, struct kbd_struct and others and where we can have what
> pointers to avoid searching. I think almost all searching could be
> avoided except when adding/removing VTs, consoles, keyboars, mice.

I have nearly done this. The old fly in the onitment is the way the
keyboard talks to the tty layer. I have right now:

struct tty_struct #1 -> struct vc_data -----|
					    |	
struct tty_struct #2 -> struct vc_data --------------> struct vt_struct
					    |	
struct tty_struct #3 -> struct vc_data -----|

> By the way, does console switching work for you in the last version on
> vgacon?

I haven't tried it. I have to make a second tree to test what we have now. 
I have the next generation of code in my tree right now.

Re: Supporting multiple keyboard

[James S. <jsi...@ac...>]

> On another note, I think you should definately not change the semantics of
> the console switching behaviour. This is used by other operating systems too,
> so if you break this, you will make Linux incompatible with quite some
> applications. (See the VT-switch handling code in the X server, as a reference).

We will keep it until the end of the developement cycle for 2.5.X. Hopefully 
the X servers will be updated by then. One it's a bad design. Two linux is
moving in a different direction than other UNIX OSes. It's would be a mess
to support the standard method and multihead at the same time. Their is
already code in the X servers that is linux specific. Adding the input
interface will add more. Using the input layer works more toward how X is
designed. X also see every device including the keyboard as a input device. 
I have been looking at the X server design to work in the input stuff.

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: Supporting multiple keyboard

[Steffen S. <s.s...@ph...>]

Petr Vandrovec wrote:
 
> On  8 Jun 00 at 9:51, James Simmons wrote:
> > > Are you sure that it is so big security hole?
> 
> > Yes :( Remeber the video memeory is shared with all VCs allocated to it.
> > Each VC has it own text buffer which make sit safe to have different apps
> > writing on different VCs at the same time. Any changes the frmaebuffer
> > mapping makes effects all the VCs attached to it. A good example is I use
> > Mesa-GGI and when I VT switch it works right. By if I VT switch back and
> > forth very rapily it locks my machine. The text buffer and framebuffer
> > contents get scrambled.
> 
> Locking machine is not security hole... It is bad bug in software...

The question is which software is to blame for the bug. The kernel for not
using a rock-solid locking mechanism? The application(s) for having to
implement independent device driver instances touching the same hardwae
in preemptive code sections?

> > > You started processes on
> > > both VT's, if you were allowed to switch them...
> >
> > This is no problem if both process are text console programs since they
> > have seperate text buffers.
> 
> If they are graphics programs, they must either explicitly disable switching
> or they must be able to handle switches correctly.

Even if they handle switches 'correctly' from a software-theoretical point
of view they could get scheduled in the middle of setting up the hardware.
This can be sufficient to lock up the machine such that only a cold-boot
can recover.  And it is more likely if you 'stress' the machine by rapidly
changing the virtual terminals. The only reason Linux came away with
this concept so far is that console switches are rare events.
Scheduling or suspending (at user's request) applications using DRI is not,
and I wonder how the DRI developers intend to fix that cleanly.

			Steffen

_______________________________________________________________________________
Steffen Seeger                              mailto:se...@ph...

Re: Supporting multiple keyboard

[Vojtech P. <vo...@su...>]

On Thu, Jun 08, 2000 at 08:06:59PM -0400, James Simmons wrote:

> That can end up being alot of devices. I see you have a ioctl to tell what
> device you are attached to. The next question is how to hand a multiheaded
> system. You don't want a user to grab someone else mouse at a workstation
> 3 offices down. Hum? We will have to think about this.

Yes.

>    I was think about keybdev.c. Not what it does now but using it to
> initailize the keyboard indepedent of CONFIG_VT. What about a system with 
> only a serial console and if someone attaches a keyboard. In this case we
> don't have /dev/tty but we should get a /dev/input/event0 for it. A cool
> app would grab data from teh keyboard and then do a write on /dev/ttyS0.
> PS/2 Keyboard data could be displayed on a serial console then :) So we
> should initalize the keyboard outside of keyboard.c to make it avaliable
> in any system. Then keyboard.c would be compiled in a VT system to be
> translate the events to a tty keymap. 

If you plug in a PS/2 keyboard (and the i8042 kbd port is active,
there is going to be some changes to better support hot-plugging PS/2
keyboards and mice) then the atkbd.c module initializes it and registers
it with the input subsystem. evdev.c gets offered the input device, and
accepts it, because it accepts any input device. It creates
/dev/input/event0. keyboard.c doesn't get offered the device, because
it's not compiled in when ve don't have VT's.

>   I'm using struct vt_struct to represent each physical VT (a display and
> a physical keyboard).

Btw, can this approach handle two displays with one keyboard?

> I'm using number in input_dev as the keyboard
> identifier in vt_struct. 

Maybe it'd be better to use struct input_handle *handle as the keyboard
identifier in the vt_struct.

> For the function kbd_keycode I pass in this
> number. This way I can look threw the vt_structs to find the VT the
> keyboard is attached to. Once I find it I have the vt_struct that
> represents this physical VT.

Searching is not nice. A better way would be to set up the handle->private
pointer to point to the VT struct - this way you don't have to search
for anything.

> The only problem is you use struct tty_struct
> which I can't readly grab from vt_struct. Hum? I'm going to have to think
> some more. I realize now I need vt_struct as a link list. A link list will
> not be that big of performace hit to search since it will never have large
> size for multihead systems. 

Well, it needs to be rethought what's is going to be in struct
vt_struct, struct kbd_struct and others and where we can have what
pointers to avoid searching. I think almost all searching could be
avoided except when adding/removing VTs, consoles, keyboars, mice.

> Ug!!! I have to think of a way to tty visiable without using ttytab. In
> the future the ttys will dynamic in number so a static array wouldn't
> work.

By the way, does console switching work for you in the last version on
vgacon?

-- 
Vojtech Pavlik
SuSE Labs

Re: Supporting multiple keyboard

[Steffen S. <s.s...@ph...>]

James Simmons wrote:

> > How X-server finds this? I'm using right-ctrl & right-alt & fX to
> > switch to tty13..25, but X server currently completely ignores it.
> 
> Since the X server puts the VT into cooked mode the X server does't knwo
> what right-ctrl & right-alt & fX means. It just reads the keyboard and
> when it sees it it send a signal to the kernel to tell it to do a VT
> switch. If you want your X server to VT switch to tty13..25 you have to
> reprogram your X server :(

Been there, done that, got the T-shirt. This is not really correct.
KGI emulates the console switching procedure of standard Linux kernel if
no fully-fledged driver is loaded. Console switching events get sent
through to applications also in raw mode (as in raw mode cooked events
get filtered by the KGI-tty driver, and only raw events are handed on, just
the oposite to cooked mode). This is binary compatible with all
applications using this scheme, the only annoying 'feature' being
that <ALT>-<Fxx> works too for switching consoles from X, and thus takes
these combinations from applications. One should use <CTRL>-<ALT>-<Fxx>
on the console just as X does, but this requires changing all the keymaps
and documentation...

On another note, I think you should definately not change the semantics of
the console switching behaviour. This is used by other operating systems too,
so if you break this, you will make Linux incompatible with quite some
applications. (See the VT-switch handling code in the X server, as a reference).

Greetings,
			Steffen

_______________________________________________________________________________
Steffen Seeger                              mailto:se...@ph...

Re: Supporting multiple keyboard

[James S. <jsi...@ac...>]

> Well, I have one /dev/input/eventX per one input devices, so that every
> application receiving input events doesn't have to get them from all
> devices in the system.

That can end up being alot of devices. I see you have a ioctl to tell what
device you are attached to. The next question is how to hand a multiheaded
system. You don't want a user to grab someone else mouse at a workstation
3 offices down. Hum? We will have to think about this.

   I was think about keybdev.c. Not what it does now but using it to
initailize the keyboard indepedent of CONFIG_VT. What about a system with 
only a serial console and if someone attaches a keyboard. In this case we
don't have /dev/tty but we should get a /dev/input/event0 for it. A cool
app would grab data from teh keyboard and then do a write on /dev/ttyS0.
PS/2 Keyboard data could be displayed on a serial console then :) So we
should initalize the keyboard outside of keyboard.c to make it avaliable
in any system. Then keyboard.c would be compiled in a VT system to be
translate the events to a tty keymap. 

  I'm using struct vt_struct to represent each physical VT (a display and
a physical keyboard). I'm using number in input_dev as the keyboard
identifier in vt_struct. For the function kbd_keycode I pass in this
number. This way I can look threw the vt_structs to find the VT the
keyboard is attached to. Once I find it I have the vt_struct that
represents this physical VT. The only problem is you use struct tty_struct
which I can't readly grab from vt_struct. Hum? I'm going to have to think
some more. I realize now I need vt_struct as a link list. A link list will
not be that big of performace hit to search since it will never have large
size for multihead systems. 

Ug!!! I have to think of a way to tty visiable without using ttytab. In
the future the ttys will dynamic in number so a static array wouldn't
work.

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: Supporting multiple keyboard

[James S. <jsi...@ac...>]

> How X-server finds this? I'm using right-ctrl & right-alt & fX to
> switch to tty13..25, but X server currently completely ignores it.

Since the X server puts the VT into cooked mode the X server does't knwo
what right-ctrl & right-alt & fX means. It just reads the keyboard and
when it sees it it send a signal to the kernel to tell it to do a VT
switch. If you want your X server to VT switch to tty13..25 you have to
reprogram your X server :( 

> Does it mean that it removes xmodmap from picture?

No. You would need it to translate from event packets from /dev/input/eventX 
to X server keyboard mapping. 

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: Supporting multiple keyboard

[James S. <jsi...@ac...>]

> Locking machine is not security hole... It is bad bug in software...

X windows also does this :( The security hole is the ablilty to write
software that can mmap the framebuffer and then vt switch via VT_ACTIVATE.
While the application is busy away on the text console the fbdev program
can be recording the info. 

> If they are graphics programs, they must either explicitly disable switching
> or they must be able to handle switches correctly.

For programs that hit the graphics hardware directly yes. Thats what the
KDSETMODE ioctl call will do. Set graphics mode and disable VT switching.
If the app wants to VT then it sets the mode back to KDSETMODE.
  
> I was talking only about security... That if you mmap /dev/fb and switch
> to syslog screen, you can get these data. It is not possible through 
> /dev/vcsa, as this can be controlled per-VT.

Thats right. I always use syslogd to recorded Oops. 

> I'd like to see some backward compatibility in picture. Until last month
> platan.vc.cvut.cz was still running '95s Slackware 3.0 (with couple of
> new things, such as glibc and kernel 2.3.33, but X was still old, non-matrox
> aware version).

Yeah. Backwards compatabilty should stay in until the end of the
developement cycle of 2.5.X. Just have the kernel print to the screen
Obsolete: Use /dev/input/eventX.

Re: Supporting multiple keyboard

[Petr V. <VAN...@vc...>]

On  8 Jun 00 at 9:51, James Simmons wrote:
> > Are you sure that it is so big security hole? 

> Yes :( Remeber the video memeory is shared with all VCs allocated to it.
> Each VC has it own text buffer which make sit safe to have different apps
> writing on different VCs at the same time. Any changes the frmaebuffer
> mapping makes effects all the VCs attached to it. A good example is I use
> Mesa-GGI and when I VT switch it works right. By if I VT switch back and
> forth very rapily it locks my machine. The text buffer and framebuffer 
> contents get scrambled. 

Locking machine is not security hole... It is bad bug in software...
 
> > You started processes on
> > both VT's, if you were allowed to switch them... 
> 
> This is no problem if both process are text console programs since they
> have seperate text buffers. 

If they are graphics programs, they must either explicitly disable switching
or they must be able to handle switches correctly.
 
> > Oops, there is special
> > case when you have syslog printing output to screen... 
> 
> While in graphics mode printk or syslog could still write to the text
> buffers instead of directly to the video memory. You also have the power
> of redirect. You can even send it to your printer.

I was talking only about security... That if you mmap /dev/fb and switch
to syslog screen, you can get these data. It is not possible through 
/dev/vcsa, as this can be controlled per-VT.

> > But oops again,
> > there is only one difference - without mmapping /dev/fb YOU have to
> > read screen and write it down, with /dev/fb software can do it for you...
> 
> I though /dev/vcsa was for that. 

/dev/vcsa* is per VT (and I hope that /dev/vcsa is process's VT and not
foreground VT), so you cannot steal information through this. But you can
through /dev/fb.

> > XF68_FBDev worked only with raw->mediumraw patch in XFree 3.3.x...
> 
> Its going to have to be patched anyways to use /dev/input/*
> 
I'd like to see some backward compatibility in picture. Until last month
platan.vc.cvut.cz was still running '95s Slackware 3.0 (with couple of
new things, such as glibc and kernel 2.3.33, but X was still old, non-matrox
aware version).
                                    Best regards,
                                            Petr Vandrovec
                                            van...@vc...
                                            

Re: Supporting multiple keyboard

[Vojtech P. <vo...@su...>]

On Thu, Jun 08, 2000 at 09:36:08AM -0400, jsi...@li... wrote:

> > Wouldn't be very useful, /dev/mouse is there for backward compatibility
> > only - as soon as we (or someone else) teach X and SVGAlib and GPM to
> > use /dev/input/event, even /dev/input/mouse can go away. The same
> > applies to /dev/input/js, but that'll take much more time - the joystick API
> > was good and there are many programs using it.
> 
> Okay. Another question is why do you have more than one /dev/input/event?
> I pictured it working like /dev/shmiq on IRIX. You open it and read a
> bunch of events coming in from a bunch of different devices. A unverisal 
> event queue. 

Well, I have one /dev/input/eventX per one input devices, so that every
application receiving input events doesn't have to get them from all
devices in the system.

They're simple char devices with no extra magic. This is ideal for X.
Should you want to implement some clever schemes with events from
different devices, and disabling events in case the VT isn't active,
best do this through the VT's.

> The way it knows if a VT switch was by watching the keys pressed and doing
> it itself. It will be awhile before all all the cards XFree86 supports is
> ported over to fbdev.

I fear this will never happen. Even the X folks have trouble getting all
cards supported in 3.3 to be also supported in 4.0.

> > And SVGAlib and all programs using it?.
> 
> Yeap. The most important being XFree86. I think SVGAlib days are over now
> that we have /dev/fb. Eventually all the video cards SVGAlib support now
> will be moved over to fbdev. As for other programs I haven't seen to many
> programs that cook the keyboard and hit the video hardware directly.

Lots of work ahead ...

-- 
Vojtech Pavlik
SuSE Labs

Re: Supporting multiple keyboard

[James S. <jsi...@ac...>]

> Are you sure that it is so big security hole? 

Yes :( Remeber the video memeory is shared with all VCs allocated to it.
Each VC has it own text buffer which make sit safe to have different apps
writing on different VCs at the same time. Any changes the frmaebuffer
mapping makes effects all the VCs attached to it. A good example is I use
Mesa-GGI and when I VT switch it works right. By if I VT switch back and
forth very rapily it locks my machine. The text buffer and framebuffer 
contents get scrambled. 

> You started processes on
> both VT's, if you were allowed to switch them... 

This is no problem if both process are text console programs since they
have seperate text buffers. 

> Oops, there is special
> case when you have syslog printing output to screen... 

While in graphics mode printk or syslog could still write to the text
buffers instead of directly to the video memory. You also have the power
of redirect. You can even send it to your printer.

> But oops again,
> there is only one difference - without mmapping /dev/fb YOU have to
> read screen and write it down, with /dev/fb software can do it for you...

I though /dev/vcsa was for that. 

> I think that it is not so big problem. Only missing part is add `hangup'
> to all these input/output devices, so that logout can cause disconnects
> for running mmap /dev/fb (or /dev/dsp...), like it disconnects backgrounded 
> processes from /dev/tty...

Yes this does need to be added.

> XF68_FBDev worked only with raw->mediumraw patch in XFree 3.3.x...

Its going to have to be patched anyways to use /dev/input/*

Re: Supporting multiple keyboard

[Petr V. <VAN...@vc...>]

On  8 Jun 00 at 9:36, jsi...@li... wrote:
> > Btw, I hope you don't mean console switching shouldn't work when in X?
> > People like to switch to and from X at runtime ...
> 
> Disabling VT switching while in graphics mode doesn't mean the X server
> has to give up VT switching. It just has to been done in a different way.
> For fbdev supported card. X server open /dev/fb and /dev/input. This
> automatically disables VT switching. Next it mmaps the framebuffer and
> goes about it business. The user wants to VT switch. The X server sees the
> event and translates it into meaning I want a VT switch. Next the X server

How X-server finds this? I'm using right-ctrl & right-alt & fX to
switch to tty13..25, but X server currently completely ignores it.
Does it mean that it removes xmodmap from picture?

                                                        Petr
                                                        

Re: Supporting multiple keyboard

[<jsi...@li...>]

> Wouldn't be very useful, /dev/mouse is there for backward compatibility
> only - as soon as we (or someone else) teach X and SVGAlib and GPM to
> use /dev/input/event, even /dev/input/mouse can go away. The same
> applies to /dev/input/js, but that'll take much more time - the joystick API
> was good and there are many programs using it.

Okay. Another question is why do you have more than one /dev/input/event?
I pictured it working like /dev/shmiq on IRIX. You open it and read a
bunch of events coming in from a bunch of different devices. A unverisal 
event queue. 

> >    What should be done? Have the system go from console to graphics mode.
> > In graphics mode the application access the raw hardware devices via
> > /dev/fb and /dev/input or /dev/event. This disables the console system.
> > Once the devices are done and they close the console system is restored. 
> 
> This is *tough*. Imagine XFree. It does everything itself - switches the
> videocard to graphic modes defined in XF8Config, has direct access to
> the graphic card's registers, has full control of the keyboard. It will
> always need to know the console is being switched.

The way it knows if a VT switch was by watching the keys pressed and doing
it itself. It will be awhile before all all the cards XFree86 supports is
ported over to fbdev. So we will have to keep KDSETMODE. Using this ioctl
will prevent VT switching while in graphics mode. This is of course
requires us to trust the program :( But with the progress of /dev/input
the X servers can support it now!

> Btw, I hope you don't mean console switching shouldn't work when in X?
> People like to switch to and from X at runtime ...

Disabling VT switching while in graphics mode doesn't mean the X server
has to give up VT switching. It just has to been done in a different way.
For fbdev supported card. X server open /dev/fb and /dev/input. This
automatically disables VT switching. Next it mmaps the framebuffer and
goes about it business. The user wants to VT switch. The X server sees the
event and translates it into meaning I want a VT switch. Next the X server
saves the frmaebuffer contents and clears the event queue. Next it cloes
both /dev/input and /dev/fb. This restores normal VT switching ablity.

> > See above. This means patches will have to be made for XFree86. 
> 
> And SVGAlib and all programs using it?.

Yeap. The most important being XFree86. I think SVGAlib days are over now
that we have /dev/fb. Eventually all the video cards SVGAlib support now
will be moved over to fbdev. As for other programs I haven't seen to many
programs that cook the keyboard and hit the video hardware directly.

Re: Supporting multiple keyboard

[Petr V. <VAN...@vc...>]

On  7 Jun 00 at 21:13, James Simmons wrote:
> userland app can access these raw devices and they ignore the VT switching
> api then can see the hardware's data. So if you open /dev/fb and mmap the
> vidoe memory then VT switch. What you type on that text console will be
> present in the framebuffers memory that another process can see. Big
> security hole.

Are you sure that it is so big security hole? You started processes on
both VT's, if you were allowed to switch them... Oops, there is special
case when you have syslog printing output to screen... But oops again,
there is only one difference - without mmapping /dev/fb YOU have to
read screen and write it down, with /dev/fb software can do it for you...

I think that it is not so big problem. Only missing part is add `hangup'
to all these input/output devices, so that logout can cause disconnects
for running mmap /dev/fb (or /dev/dsp...), like it disconnects backgrounded 
processes from /dev/tty...

> > MediumRaw is seldomly used - and is event numbers again. 
> 
> Do you think we can get ride of it? I vote to get ride of it.

XF68_FBDev worked only with raw->mediumraw patch in XFree 3.3.x...
 
                                        Best regards,
                                                Petr Vandrovec
                                                van...@vc...
                                                                   

Re: VTs and multiple keyboards

[Vojtech P. <vo...@su...>]

On Wed, Jun 07, 2000 at 10:03:49PM -0400, James Simmons wrote:
> 
> Now that I understand the way the keyboard <-> tty works like for ruby.
> 
> -------------------------------------------------------------------------
> 
> Ruby way for AT keyboards:
> 
> i8042.c -(raw)-> atkbd.c -(events)-> input.c -->
> >--(events)-> keyboard.c -(chars)-> tty
> 
> Ruby way for USB keyboards:
> 
> usb.c -(usb)-> hid.c -(events)-> input.c -->
> >--(events)-> keyboard.c -(chars)-> tty
> 
> -----------------------------------------------------------------------
> 
> The next question is can we have 
> 
>  i8042.c            usb.c  
>    |                  | 
>  (raw)              (usb) 
>    |                  |
>  atkbd.c            hid.c 
>    |                  |
>  (events)           (events)
>    |                  |
>    |                  |
>  input.c            input.c      
>    |                  |     
>    --------(events)-----------> keyboard.c -(chars)-> tty
> 
> I'm assuming only specific EV_KEY events get sent to keyboard.c. If
> keyboard.c only sees events coming in and we want to support multiple
> keyboards how are we going to tell the different keyboards apart? Wait I
> think I see how. We have
> 
> void kbd_event(struct input_handle *handle, unsigned int event_type, 
>                unsigned int keycode, int down)
> {
>         if (event_type != EV_KEY) return;
>         kbd_keycode(keycode, down);
>         tasklet_schedule(&keyboard_tasklet);
> }
> 
> In input_handle we have input_dev *dev which has a name string whcih I can
> use compare which keyboard it came from. I think? Ideas Vojtech.

Not just a name, you also have the idbus, idvendor, idproduct,
idversion, *number* variables in struct input_dev. I hope to add
tbus, tdev, tfunc or something like that to identify where the device is
in the bus topology.

When a keyboard (or other input device) is found, the kbd_connect
function is called. The function then looks at the device, and if it
likes it, it can open it and get events from it. In this (kbd_connect)
function, we should decide which VTs to bind that keyboard to initially. 

The handle struct also has a 'private' pointer, which can be used to
associate any private data with the handle struct, so we always know
what keyboard is that.

-- 
Vojtech Pavlik
SuSE Labs

Re: Supporting multiple keyboard

[Vojtech P. <vo...@su...>]

On Wed, Jun 07, 2000 at 09:13:01PM -0400, James Simmons wrote:

> Thank you for the clarification. Actually I have anothe question for
> you but this email has become to long so I will post another message. The
> next question is what is difference between /dev/input and /dev/event?

None. Actually the correct name for the devices is:

/dev/input/event0
/dev/input/event1
/dev/input/event2
/dev/input/event3

and so on. Input being the subdirectory in /dev for the eventX, mouseX
and jsX devices.

-- 
Vojtech Pavlik
SuSE Labs

VTs and multiple keyboards

[James S. <jsi...@ac...>]

Now that I understand the way the keyboard <-> tty works like for ruby.

-------------------------------------------------------------------------

Ruby way for AT keyboards:

i8042.c -(raw)-> atkbd.c -(events)-> input.c -->
>--(events)-> keyboard.c -(chars)-> tty

Ruby way for USB keyboards:

usb.c -(usb)-> hid.c -(events)-> input.c -->
>--(events)-> keyboard.c -(chars)-> tty

-----------------------------------------------------------------------

The next question is can we have 

 i8042.c            usb.c  
   |                  | 
 (raw)              (usb) 
   |                  |
 atkbd.c            hid.c 
   |                  |
 (events)           (events)
   |                  |
   |                  |
 input.c            input.c      
   |                  |     
   --------(events)-----------> keyboard.c -(chars)-> tty

I'm assuming only specific EV_KEY events get sent to keyboard.c. If
keyboard.c only sees events coming in and we want to support multiple
keyboards how are we going to tell the different keyboards apart? Wait I
think I see how. We have

void kbd_event(struct input_handle *handle, unsigned int event_type, 
               unsigned int keycode, int down)
{
        if (event_type != EV_KEY) return;
        kbd_keycode(keycode, down);
        tasklet_schedule(&keyboard_tasklet);
}

In input_handle we have input_dev *dev which has a name string whcih I can
use compare which keyboard it came from. I think? Ideas Vojtech.

Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.

James Simmons  [jsi...@li...]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net