Re: hijacled q

[Aivils S. <ai...@un...>]

On Piektdiena, 9. Septembris 2005 20:16, Hugo Vanwoerkom wrote:
> Good explanation.
>
> In any case: with faketty like this:
>
> lrwxrwxrwx =A01 root root =A0 10 2005-09-09 01:51
> /dev/tty50 -> /dev/ftty1
> lrwxrwxrwx =A01 root root =A0 10 2005-09-09 01:51
> /dev/tty51 -> /dev/ftty0
>
> and gdm running X1 to vt51 and X0 to vt7
> (AGP TNT2 + MX-440 PCI)
>
> and hijacled NOT running,
>
> I can write to LEDs of tty1-7 and they function.
> I can hit caps lock on both kbds and get the LED on.
> But I cannot write to tty51 (cannot open...) nor to
> tty50 (vc's don't switch).
>
> With Ruby I could write to tty17 that X1 was running.

faketty was developed for X as user target application.
=46or normal input event processing via ftty device node, that
device must be used exclusive, all input events goes
to ftty only. X just know how to open device and perform
some ioctl's. faketty grant exclusive access for 1st=20
opener user application. Secondary opening is meaningless,
because device is grabed and should not send any event to
2nd, 3rd ... opener application.

In Your case seems i schedule next version of faketty, where
PC speaker is in use and ftty device nodes works in native
kernel way even that way is not sane from my point of view.
Anyway 1st opener grab device. 2nd opener can perform ioctl's
only.

Aivils Stoss