|
From: Zoltan B. <zb...@fr...> - 2006-05-13 08:08:56
|
Hi,
Aivils Stoss =EDrta:
> On Ceturtdiena, 11. Maijs 2006 00:15, Zoltan Boszormenyi wrote:
> =20
>> Hugo Vanwoerkom =EDrta:
>> =20
>>> --- Zoltan Boszormenyi <zb...@fr...> wrote:
>>> =20
>>>> Hi,
>>>>
>>>> first, I would like to thank you for the faketty
>>>> module,
>>>> I stopped maintaining the ruby patch and was able to
>>>> quickly
>>>> restore my multihead machine after upgrading to FC5.
>>>>
>>>> I would like to know what do you think about the
>>>> following modifications.
>>>>
>>>> - Instead of the "ftty%d" device names, use "tty%d",
>>>> count from the number of normal TTY devices and
>>>> up,
>>>> e.g. ftty0 -> tty64, etc.
>>>> - RC script now don't delete tty devices to create
>>>> symlinks.
>>>> - Also, RC script can use the "chkconfig" facility,
>>>> use
>>>> "make install-service-rh" to install it that way.
>>>>
>>>> Best regards,
>>>> Zolt=EF=BF=BDn B=EF=BF=BDsz=EF=BF=BDrm=EF=BF=BDnyi
>>>> =20
>>> And the reason for changes? I kind of like it the way
>>> it is.
>>>
>>> Hugo
>>> =20
>> Reason #1: It's not really legal to delete device nodes that are
>> controlled by another driver.
>> =20
>
> Driver didn't control device node, which is tricky access of
> special features. Node was created by system operator (nowadays smart
> script) can be deleted by system operator. Agree, deleting is not
> correct against another drivers.
> Of course faketty starting script created without long thinking.
> Not once opened nodes deleted careless.
>
> =20
>> Reason #2: Given #1 above, it would be more useful to just
>> create links as /dev/tty64 and up and still have ftty devices.
>> It would be best to use an udev rule, but I haven't seen any way
>> to do it. E.g. suppose that SYMLINK command can use options,
>> and %m gives you the minor number of the device it has just created,
>> this latter being an existing udev feature. Now, a rule like this woul=
d do:
>> KERNEL=3D=3D"ftty" GROUP=3D"tty" MODE=3D"0660", SYMLINK=3D"tty(64+%m)"
>>
>> But you cannot really detect the maximum number of the TTY device node=
s
>> just by looking at them, something else may have deleted them, too.
>> As I see now, the only reliable way to detect the next number is using
>> "MAX_NR_CONSOLES + 1" for the running kernel.
>> I would be happy to be proven wrong, though.
>> =20
>
> I suppose this is spliting of hairs. Should we ask for name to Linus
> Torvald? i read out linux/Documentation/devices.txt again, but that doe=
s
> not give solution for me. i have not plans to include faketty in
> mainstream kernel. faketty have public release.
>
> Aivils Stoss
> =20
I just learned that patching faketty is not necessary.
XOrg/XFree86 has two keyboard drivers, the built-in "keyboard" and
the loadable "kbd". If you use the "kbd" driver, you can specify
the device it has to drive, so e.g. this works:
Section "InputDevice"
Identifier "kbd0"
Driver "kbd"
Device "/dev/ftty0"
...
EndSection
Multiple keyboards could be assigned to an X server,
so e.g. as my USB keyboard provides two input devices,
one for the normal keys and I guess the other for the
multimedia keys, both could be assigned to one of the X servers.
The bttv card's input device also could be used, so LIRC enabled
software can be used, too.
So, deleting /dev/tty5* isn't necessary either, one has to specify
the device in the InputDevice sectionin xorg.conf/XF86Config
instead of the Xserver command line as vtX.
Sorry for the noise.
Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi
|