4.3.3 bugs

[Duncan]

James Tyrer posted on Sat, 14 Nov 2009 15:12:49 -0700 as excerpted:

>>> xorg.conf has "/dev/input/mice".
>> 
>> /dev/input/mice is a kernel "emulated" mouse.  It takes whatever it
>> sees and emulates a ps2 Microsoft Explorer mouse with it.  That's why
>> I'm saying it shouldn't matter.
>> 
> Some documentation suggests using: "/dev/input/mouse0".  Does this make
> a difference?

The difference it would make would be if you had multiple mice.  The 
multi-pointer-X changes that are just coming online now (with xorg-
server-1.7 and newer, AFAIK) affect things a bit, but previously, using
/dev/input/mice was supposed to be the more trouble-free way, if you 
tended to switch between devices, since it would see and use them all 
without the complications one would otherwise have switching between 
them.  Using the old configuration style, /dev/input/mice allowed you to 
configure just it, instead of having to configure multiple device 
entries, one for each mouse, choosing one as X's corepointer, etc...

As I said, multi-pointer-X changes the rules a bit, there.  I'm not 
exactly sure how it all works, but I do know that multi-point touch-pads 
and the like can be configured with special "pinch" movements (commonly 
used for zoom), etc, tracking two different touch-points on the same 
device.  Of course-pre-multi-pointer, the two points would be averaged 
into a single point somewhere between the two...  Anyway, apparently, 
it's possible to do roughly the same thing using two separate more 
conventional pointing devices (mice, trackballs, etc) or a single-point 
touchpad and a second device.  The pinch type movements would seem to be 
rather more artificial (less natural/intuitive) in that case, but other 
things become more natural/intuitive -- things like dragging opposite 
corners of a window to resize it both ways at once, perhaps moving and 
resizing a window both at the same time, etc.

Of course, if you're doing that using two different devices, you'll need 
to use the individual /dev/input/mouseX devices -- either that or the 
evdev driver and device, which works differently, basically reporting 
"events" for all input devices, rather than tracking movement and/or keys 
on just one.  You'd certainly /not/ want to use the general 
/dev/input/mice in that case, because it'd simply average them all, which 
isn't the desired effect if you're deliberately tracking more than one, 
actually using the separate outputs to enable various tasks not otherwise 
simply doable.

>> What mouse type are you telling xorg to use,
> 
>      Driver	"mouse"
>      Option      "Protocol" "IMPS/2"
>      Option 	"Device" "/dev/input/mice"
> 
>> and is it
> 
> Pronoun reference please.  Is what set?

I was wanting the protocol for one thing, imps/2 in this case.  That 
should be fine.  But I also had in mind the possible intervention of hal, 
which would then cause your xorg settings to be ignored entirely... but 
you get more into that, below.

Given the info so far, the xorg.conf settings look like they should be 
correct... tho we don't know if it's actually using them, just yet.  But 
if they're being used, and there's an issue, it' looks like a bug, to 
me.  It may be something with your individual compilation (cflags and the 
like come into play here, things like -ftree-vectorize, one of the cflags 
I'm using, could have strange effects if the app doesn't expect them to 
be used... and of course there's occasional bugs in gcc itself... that 
may only appear under specific conditions).

>> set to use the xorg.conf setting or hal (with server 1.6 and possibly
>> 1.5, IDR ATM, it would ignore the xorg.conf setting and use hal, unless
>> you set a serverflag telling it not to.  I don't have time ATM to look
>> at the details, but the xorg.conf manpage has them I believe.)
>> 
> I do not have:
> 
> 	Option "AutoAddDevices"
> 	Option "AutoEnableDevices"
> 
> in my xorg.conf file.  IIUC, they are both true by default.
> 
> The man pages are not really adequate documentation. :-|

One of the frustrations with manpages, is that in general they're really 
not designed to be intros to the topic, but rather, either really in 
depth coverage for stuff people already understand the basic concepts of, 
or "cheat sheets", for people that already know the material, and just 
need a reminder of the specific syntax or whatever.  They do generally 
cover that intended purpose, but finding someplace that covers the basic 
concepts is unfortunately far more difficult in way too many cases.  
That's just a problem of *ix in general, I think.  OTOH, the info is 
generally out there in some form if you're persistent enough, not always 
the case with proprietaryware, unless you're up to reverse engineering 
it, of course. =:^(

But I've had enough of an intro, the manpages do tend to work for their 
intended purpose here, so let me refresh a bit and see if I can explain 
the ideas a bit better.

OK...

... Here's the deal:  The ultimate goal is to have it "just work" without 
an xorg.conf at all, for most people, AND have it "just work" "live", 
interpreted as, keyword "hotplug", aka "plug-n-play", altho as every geek 
surely knows, unfortunately, that's all too often
"plug-n-pray"!  Of course, multiple monitors, etc, while they might be 
pnp, will need some sort of config telling X what orientation to use, 
etc, unless people are happy with it being random, or whatever 
(especially because in many cases, the order the monitors are detected 
may not be the same every time).  But the goal is for the simple case to 
be pnp and for it all to "just work", without an xorg.conf at all.

Keeping that goal in mind...  plus the goal of simplification, that is, 
if someone only wanted to control the relative positions of their 
monitors, and thus had that setup in their xorg.conf, that shouldn't 
prevent the OTHER elements from being pnp... IOW, the setup should still 
function without everything else being specified just because one thing 
needed to be specified...

Based on that...

The "magic" option for most people is actually a third one, that you 
didn't mention, above:

	Option "AutoAddDevices"

There are actually two separate conditionals that control the default, 
here, and the wording of the manpage, while it does mention the 
conditions, is NOT such that it's AT ALL clear to the uninitiated that 
this is REALLY the controlling option they need to be worried about.

The key to understanding why it works the way it does, is just as I said 
above, because they had to arrange it such that the defaults "just 
worked", at least ideally, even if the user did something stupid with 
their xorg.conf.  The /problem/ of course, is that such a default just 
looks like either deliberate obfuscation or incredible stupidity of 
design, to the geek/sysadmin type that never-the-less isn't yet initiated 
into the intricacies of hal-controlled-X.

Read in that light, the manpage entry begins to make a bit more sense.  
The KEY bit is "Enabled by default"!!!!  This is absolutely OPPOSITE the 
GENERAL rule, as defined at the top of the manpage, where NOT having the 
option at all (or if it's there but commented out) means it's DISABLED, 
and that's the problem, for folks used to dealing with xorg.conf, since 
it breaks the normal assumptions into bits!

Now, that "enabled by default" bit gets obfuscated by the "if...", but 
the key to interpreting the if clause is to realize that the other two 
are enabled by default, as well, again, breaking the general rule.  And 
again, this makes NO sense at all to the sysadmin who's used to dealing 
with xorg.conf and simply assumes that an option that doesn't appear, or 
is commented, is disabled, because that's the way it has always worked, 
and that's the way it is explained to work, at the top of the manpage.  
But, the reason they chose to do it this way in SPITE of all that, is 
because they were trying to make pnp "just work", and in ordered to do 
so, they broke a few of the traditional rules along the way.

Got that?

So what this all boils down to is the following:  *UNLESS* you have

	Option "AllowEmptyInput" "false"

and CONTRARY to all intuition and general sysadmin good sense otherwise,
XORG WILL NORMALLY FLAT IGNORE YOUR XORG.CONF input settings ENTIRELY, 
and use hal.  In fact, if hal gets screwed up and for whatever reason 
doesn't detect and supply xorg with the proper settings, xorg will STILL 
want to ignore your xorg.conf settings, and will to the poor sysadmin's 
COMPLETE befuddlement, come up without any responsive input whatsoever, 
and sit their happily updating the time and various plasma widgets (in 
the context of KDE4 here, of course), but ignore all attempts at 
interaction whatsoever, no matter WHAT xorg.conf has to say about the 
input devices, and even if they're otherwise 100% correct -- all due to 
that single missing Option line that breaks all the rules by being 
enabled if it's NOT there!!

The AutoAddDevices and AutoEnableDevices are, as one of my friends would 
say, rabbit trails.  For the rabbits that need and use them, they might 
be very useful indeed, but they only serve to obfuscate and detour the 
reader from the important bit, that AllowEmptyDevices is the key to the 
entire thing, and that it breaks the normal rules, by being enabled in 
its absence!

As a result of all this, a LOT of people have had serious headaches 
trying to figure out what has gone wrong with their previously perfectly 
working devices, which according to all the documentation (if one doesn't 
see this big trap waiting to spring on them!), are STILL setup 
correctly.  And all those headaches "magically" simply disappear, when 
the proper 'Option "AllowEmptyInput" "false"' incantation is placed in 
their xorg.conf!  So most ultimately end up googling and finding the 
proper incantation, at least one would /hope/ so, but how many actually 
understand why, counter to every sysadmin instinct they've ever had, it 
actually works the way it does, and all the otherwise proper settings 
were flat ignored, without this incantation?

If it's not /completely/ obvious by now, I find this intensely obtuse and 
frustrating myself, and can't /help/ but think there MUST have been some 
other, less obtuse, less counter-intuitive, less seemingly deliberate 
violation of all that a sysadmin holds sacred... SOMETHING, ANYTHING, 
other than THIS!!!

Anyway, hope that helps.  Given the situation, chances are quite good 
that your xorg is using a setup you hadn't the foggiest about, while 
completely ignoring the one you painstakingly verified to be the correct 
one, that you had every reason in the world to believe was being used 
just as you'd configured it.  You're just lucky you found it this way, 
instead of having it break, and spending hours trying to figure out why 
the "proper" configuration wasn't working at all.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.