Re: faketty is not needed with XOrg-7.x

[Zoltan B. <zb...@fr...>]

Hugo Vanwoerkom =EDrta:
> --- Zoltan Boszormenyi <zb...@fr...> wrote:
>
>  =20
>> Zoltan Boszormenyi =EF=BF=BDrta:
>>    =20
>>> Hugo Vanwoerkom =EF=BF=BDrta:
>>>  =20
>>>      =20
>>>> --- Zoltan Boszormenyi <zb...@fr...>
>>>>        =20
>> wrote:
>>    =20
>>>>  =20
>>>>    =20
>>>>        =20
>>>>> Hugo Vanwoerkom =EF=BF=BDrta:
>>>>>    =20
>>>>>      =20
>>>>>          =20
>>>>>> */Zoltan Boszormenyi <zb...@fr...>/*
>>>>>>      =20
>>>>>>        =20
>>>>>>            =20
>>>>> wrote:
>>>>>    =20
>>>>>      =20
>>>>>          =20
>>>>>>     Hi,
>>>>>>
>>>>>>     I just noticed that faketty isn't needed
>>>>>>            =20
>> with
>>    =20
>>>>>>      =20
>>>>>>        =20
>>>>>>            =20
>>>>> Xorg 7.x.
>>>>>    =20
>>>>>      =20
>>>>>          =20
>>>>>>     The following section works like a charm
>>>>>>            =20
>> for a
>>    =20
>>>>>>      =20
>>>>>>        =20
>>>>>>            =20
>>>>> keyboard,
>>>>>    =20
>>>>>      =20
>>>>>          =20
>>>>>>     nothing else is needed.
>>>>>>
>>>>>>     Section "InputDevice"
>>>>>>     Identifier "Keyboard0"
>>>>>>     Driver "evdev"
>>>>>>     Option "Device" "/dev/input/eventX"
>>>>>>     Option "XkbLayout" "hu"
>>>>>>     EndSection
>>>>>>
>>>>>>     The proper eventX device is registered in
>>>>>>      =20
>>>>>>        =20
>>>>>>            =20
>>>>> /proc/bus/input/devices
>>>>>    =20
>>>>>      =20
>>>>>          =20
>>>>>>     and as with the kbd driver, multiple
>>>>>>            =20
>> sections
>>    =20
>>>>>>      =20
>>>>>>        =20
>>>>>>            =20
>>>>> can be listed
>>>>>    =20
>>>>>      =20
>>>>>          =20
>>>>>>     and assigned to the same server, e.g. the
>>>>>>            =20
>> PS/2
>>    =20
>>>>>>      =20
>>>>>>        =20
>>>>>>            =20
>>>>> keyboard
>>>>>    =20
>>>>>      =20
>>>>>          =20
>>>>>>     and the BTTV remote is assigned to one X
>>>>>>      =20
>>>>>>        =20
>>>>>>            =20
>>>>> server,
>>>>>    =20
>>>>>      =20
>>>>>          =20
>>>>>>     the USB keyboard's two devices (normal
>>>>>>      =20
>>>>>>        =20
>>>>>>            =20
>>>>> keyboard and
>>>>>    =20
>>>>>      =20
>>>>>          =20
>>>>>>     the multimedia keys are separated) are
>>>>>>      =20
>>>>>>        =20
>>>>>>            =20
>>>>> assigned to the
>>>>>    =20
>>>>>      =20
>>>>>          =20
>>>>>>     other server.
>>>>>>
>>>>>> And what is the vt set at then in gdm.conf for
>>>>>>            =20
>> the
>>    =20
>>>>>>      =20
>>>>>>        =20
>>>>>>            =20
>>>>> other keyboards?
>>>>>    =20
>>>>>      =20
>>>>>          =20
>>>>>> Hugo
>>>>>>      =20
>>>>>>        =20
>>>>>>            =20
>>>>> Nothing, but "-sharevts" is needed. Same for
>>>>>          =20
>> faketty
>>    =20
>>>>> if I don't specify "vtX" on the parameter line
>>>>>          =20
>> and
>>    =20
>>>>> use
>>>>>  Option "Device" "/dev/fttyN" instead.
>>>>>
>>>>> But some bug may still exist in the X evdev
>>>>>          =20
>> driver
>>    =20
>>>>> as hungarian layout doesn't work correctly.
>>>>> E.g. Option "XkbModel" "pc105" makes RightAlt
>>>>> behave as Enter and without it (e.g. working as
>>>>> pc104),
>>>>> my i-acute button doesn't work.
>>>>>
>>>>> So, XOrg is only starting to get there, I
>>>>>          =20
>> switched
>>    =20
>>>>> back to faketty for now.
>>>>>
>>>>>
>>>>>    =20
>>>>>      =20
>>>>>          =20
>>>> I just tried this with good success. But I only
>>>>        =20
>> have 2
>>    =20
>>>> monitors/keybds/mice.
>>>> The keyboards are both IBM Model M's. Mine is now
>>>>        =20
>> 13
>>    =20
>>>> years old and the other I bought for $57 new.
>>>> Also I only need dead keys for us-intl config.
>>>>
>>>> So Faketty is gone and xorg.conf relevant parts
>>>> becomes:
>>>>
>>>> ...
>>>> Section "InputDevice"
>>>>         Identifier       "Keyboard0"
>>>>         Driver           "evdev"
>>>>         Option           "Device"       =20
>>>> "/dev/input/event0"
>>>>         Option           "XkbLayout"    =20
>>>>        =20
>> "us_intl"
>>    =20
>>>> EndSection
>>>> ...
>>>> Section "InputDevice"
>>>>         Identifier       "Keyboard1"
>>>>         Driver           "evdev"
>>>>         Option           "Device"       =20
>>>> "/dev/input/event1"
>>>>         Option           "XkbLayout"    =20
>>>>        =20
>> "us_intl"
>>    =20
>>>> EndSection
>>>> ...
>>>>  =20
>>>>    =20
>>>>        =20
>>> I replaced the 'Option "Device"  ... ' lines with
>>> 'Option "Phys" "..."', it gives the same effect
>>>      =20
>> but
>>    =20
>>> with higher persistency. It turned out that
>>>      =20
>> modprobe
>>    =20
>>> processes race with each other and bttv and USB
>>>      =20
>> HID
>>    =20
>>> devices change their places (both /dev/fttyN and
>>> /dev/input/eventN)  depending on the load order.
>>>  =20
>>>      =20
>> And for my non-working iacute button, I needed this:
>>
>>    =20
> https://launchpad.net/distros/ubuntu/+source/xkeyboard-config/+bug/4284=
6
>  =20
>> I had to put this only line in
>> /usr/share/X11/xkb/keycodes/evdev :
>>
>> <LSGT> =3D 94
>>
>> And the only key that wasn't working before
>> now works with evdev. Bye-bye faketty. :-)
>>
>>    =20
>
> I have set 'Option "Phys" "..."'"as you indicated.
>
> Here's the weird one *without* Faketty:
>
> 1. I run fvwm window-manager. Start either FF or
> Seamonkey. Activate xcompmgr to start translucent
> windows with the Alt+F9 key combination. It executes
> /usr/local/bin/xcompmgr -c.
>
> 2. Switch to vt1 with Alt+F1
>
> 3. From vt1 switch back with Alt+F7
>
> IF IN FF OR SEAMONKEY THE HELP SCREEN WILL BE SHOWN!
>
> Turn off translucent windows (kill the xcompmgr's pid)
> AND EVERYTHING IS NORMAL AGAIN!
>
> Got a clue on how to avoid that? I posted to
>  =20

Hm, don't switch to vt1 then? :-)
I guess it's a "doctor it hurts - don't do it then"
type of a problem. I think it's not too fortunate
to mix /dev/tty* usage with direct keyboard access.
/dev/tty* will multiplex all the keyboards, because
it may steal input from other devices, too.
BTW the latest RawHide 2.6.18-rc1 based kernels
ruined NumLock handling again, my USB keyboard
controls the PS/2 keyboard's NumLock when on the
console and at least the LEDs don't work on the USB
keyboard after X grabbed it.

> mozilla.support.seamonkey on how to disable shortcuts
> but not too much luck.
>
> Why run with translucent windows? Who knows, I like
> it, it took me a year to get it finally working.
>  =20

What about compiz? It works pretty fast on my Radeon 9200SE.
I will try it on the Radeon 7000, too.

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi