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 |