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.
