Mailing List Archive

On Wed, 14 Nov 2012 14:18:46 -0500
Frank Peters <frank.peters@comcast.net> wrote:

> My system is updated daily and I use only the
> Fvwm window manager (no Gnome or K).

With a similar setup I've had no problems using
evdev. The first step was to unlink xorg.conf.

At that point everything Just Worked.

If you want an xorg.conf then try using

X -configure;

as SU and see what it gives you -- after installing
evdev.

Q: Do you have any other USB devices on the system?

There may be something else that is hogging the bus
(e.g., flakey flash drive) and causing timeouts with
the KB. Could also be a flakey USB port or keyboard
hardware. In my experience, purely random flakeyness
is more likely to be a hardware issue.

In any case, I'm happily running with fvwm 2.6.3,
INPUT_DEVICES="evdev", and no xorg.conf whatever.

--
Steven Lembark 3646 Flora Pl
Workhorse Computing St Louis, MO 63110
lembark@wrkhors.com +1 888 359 3508

What input drivers you're using?


2012/11/14 Frank Peters <frank.peters@comcast.net>

> Hello,
>
> Lately I have been experiencing a strange problem. Under X my USB keyboard
> will suddenly stop working. If I press some keys they will not appear in
> an
> X console or in any other application. There is no warning. It just
> will sporadically stop working. Usually, if I wait for several minutes
> the keys will start working again.
>
> Fortunately, the USB mouse will continue to function normally during these
> episodes. If I then immediately shutdown X using some mouse clicks, I will
> again have a working keyboard. Also, the last few keys I had pressed
> before
> shutting down X will appear in my console. This would mean that the key
> presses are detected and placed into the buffer but somehow the X
> applications
> do not receive them.
>
> I cannot pinpoint the start of this behavior to any specific system
> changes,
> but I suspect that the latest nvidia-drivers may be the source of the
> problem.
> The problem seems to coincide with one of the several nvidia updates, but
> this is still a guess.
>
> My system is updated daily and I use only the Fvwm window manager (no
> Gnome or K).
>
> How can I debug this further? Both the kernel log and the X log show
> nothing
> whatever.
>
> Frank Peters
>
>
>

Am 14.11.2012 20:18, schrieb Frank Peters:
> Hello,
>
> Lately I have been experiencing a strange problem. Under X my USB keyboard
> will suddenly stop working. If I press some keys they will not appear in an
> X console or in any other application. There is no warning. It just
> will sporadically stop working. Usually, if I wait for several minutes
> the keys will start working again.
>
> Fortunately, the USB mouse will continue to function normally during these
> episodes. If I then immediately shutdown X using some mouse clicks, I will
> again have a working keyboard. Also, the last few keys I had pressed before
> shutting down X will appear in my console. This would mean that the key
> presses are detected and placed into the buffer but somehow the X applications
> do not receive them.
>
> I cannot pinpoint the start of this behavior to any specific system changes,
> but I suspect that the latest nvidia-drivers may be the source of the problem.
> The problem seems to coincide with one of the several nvidia updates, but
> this is still a guess.
>
> My system is updated daily and I use only the Fvwm window manager (no Gnome or K).
>
> How can I debug this further? Both the kernel log and the X log show nothing
> whatever.
>
> Frank Peters
>
>

I think you just have to bite the bullet and start swapping parts of
your setup until the error disappears: Try a different keyboard, or a
different USB port. Use different (older + newer) versions of
xorg-server, xf86-input-evdev and so forth.

On Wed, 14 Nov 2012 17:31:50 -0200
Luis Gustavo Vilela de Oliveira <luisgustavo.vilela@gmail.com> wrote:

> What input drivers you're using?
>

xf86-input-mouse-1.8.1
xf86-input-keyboard-1.6.2

Also, I am not using the auto configuration but I have a custom X config file.

Frank Peters

Try use only evdev instead. Looks like is some problem with the input drive
that u are using.


2012/11/14 Frank Peters <frank.peters@comcast.net>

> On Wed, 14 Nov 2012 17:31:50 -0200
> Luis Gustavo Vilela de Oliveira <luisgustavo.vilela@gmail.com> wrote:
>
> > What input drivers you're using?
> >
>
> xf86-input-mouse-1.8.1
> xf86-input-keyboard-1.6.2
>
> Also, I am not using the auto configuration but I have a custom X config
> file.
>
> Frank Peters
>
>
>

On Wed, 14 Nov 2012 20:43:47 +0100
Florian Philipp <lists@binarywings.net> wrote:

>
> I think you just have to bite the bullet and start swapping parts of
> your setup until the error disappears: Try a different keyboard, or a
> different USB port. Use different (older + newer) versions of
> xorg-server, xf86-input-evdev and so forth.
>

It's a software problem. When the keyboard stops I can immediately
shut down X and it will be working. The hardware is not the fault.

You are probably correct. Currently, I am rather busy with other
things and can't take the time to do much software downgrades and
comparisons. For the moment, at least, my solution will be to
stop and then restart X.

But if things do not clear up, I eventually will have to search for
a way to debug or get some sort of diagnostic output.

Frank Peters

Frank Peters, mused, then expounded:
> On Wed, 14 Nov 2012 20:43:47 +0100
> Florian Philipp <lists@binarywings.net> wrote:
>
>
> It's a software problem. When the keyboard stops I can immediately
> shut down X and it will be working. The hardware is not the fault.
>

Rebuild your hardware drivers - keyboard, mouse, etc. Look in the
xorg-server ebuild and it'll say -

emerge portage-utils; qlist -I -C x11-drivers/

Then rebuild the drivers on the list, if you haven't.

The other cause might be dbus.

Bob

--
-

On Wed, 14 Nov 2012 16:45:27 -0500, Frank Peters
<frank.peters@comcast.net> wrote:
> For the moment, at least, my solution will be to
> stop and then restart X.

If I may, I suggest that you try the evdev solution that some others have
pointed out. The package is xf86-input-evdev, and it replaced your mouse
and keyboard drivers as one unified driver. I believe it may require
adjusting your xorg.conf since you have a custom one.

According to [0], which admittedly did not cite a source (and I'm lazy so
I didn't do much searching), the evdev driver obsoletes the keyboard and
mouse driver. I seem to recall that there was a Gentoo news or something
about this a while back too, saying that keyboard and mouse were obsolete,
but I again am lazy and haven't even attempted to find that :)

[0] http://en.gentoo-wiki.com/wiki/X.Org/Mouse

--
R

On Wed, 14 Nov 2012 17:06:54 -0500
"Randy Barlow" <randy@electronsweatshop.com> wrote:

>
> If I may, I suggest that you try the evdev solution that some others have
> pointed out.
>

Yes, I have known about evdev for a long time, but since everything has
worked very well on my system I have had no motivation to change. "If it
ain't broke, don't fix it."

I can research what needs to be done to change over to using evdev.

But if the legacy keyboard and mouse drivers have been made obsolete
by evdev, then why are they still being distributed? Is it only to
accommodate older systems?

Frank Peters

On Wed, 14 Nov 2012 18:11:12 +0000
Steven Lembark <lembark@wrkhors.com> wrote:

>
> In my experience, purely random flakeyness
> is more likely to be a hardware issue.
>
> In any case, I'm happily running with fvwm 2.6.3,
> INPUT_DEVICES="evdev", and no xorg.conf whatever.
>

I have a spare keyboard (brand new) that I can attach. If the
problem persists then I'll have to switch over to evdev -- but
that won't be for a few weeks yet.

Thanks for all the responses.

Frank Peters

Randy Barlow posted on Wed, 14 Nov 2012 17:06:54 -0500 as excerpted:

> On Wed, 14 Nov 2012 16:45:27 -0500, Frank Peters
> <frank.peters@comcast.net> wrote:
>> For the moment, at least, my solution will be to stop and then restart
>> X.
>
> If I may, I suggest that you try the evdev solution that some others
> have pointed out. The package is xf86-input-evdev, and it replaced your
> mouse and keyboard drivers as one unified driver. I believe it may
> require adjusting your xorg.conf since you have a custom one.
>
> According to [0], which admittedly did not cite a source (and I'm lazy
> so I didn't do much searching), the evdev driver obsoletes the keyboard
> and mouse driver. I seem to recall that there was a Gentoo news or
> something about this a while back too, saying that keyboard and mouse
> were obsolete,
> but I again am lazy and haven't even attempted to find that :)
>
> [0] http://en.gentoo-wiki.com/wiki/X.Org/Mouse

Yes, evdev is the standard replacement for both the X keyboard and mouse
drivers. There's a couple things to note, however:

* There's a kernel option that must be turned on as well. If it's not,
the evdev driver won't find the devices to work with (CONFIG_INPUT_EVDEV,
listed as "Event interface" under device drivers, input device support,
generic input layer).

* If you run gpm for text console mouse support, you still need the
kernel's mouse interface (CONFIG_INPUT_MOUSEDEV, providing
/dev/input/mice and /dev/input/mouseX) turned on. Otherwise you can turn
it off. It doesn't interfere with evdev.

* If you run special purpose hardware like touchpads (the syntouch
driver), you can still use those instead if you wish. However, evdev
should work for the vast majority of cases, and can be used for most
special purpose including touchpad devices as well, except it doesn't
have all the extra touchpad (or other hardware) specific configuration
options.


* An additional more general point about xorg.conf. As others have
suggested, it's rarely needed now, except for specifying "unusual"
configurations such as the orientation of multiple monitors if you're
using them, non-default drivers and/or driver options (the syntouch
driver, or mouse accel options, for instance), etc. And for that,
multiple individual *.conf files in /etc/X11/xorg.conf.d/, each with a
section or more with its non-default options, works better for many than
a single monolithic xorg.conf file does.

Here, I have four such *.conf files, one with the "Device" section for my
graphics card (with as I said a few non-default settings), one for my
"InputClass" sections (trackball accel settings on my main machine,
syntouch settings on my netbook, an Option "Ignore" section for the HDMI
audio on my graphics card and another for the /dev/input/mouseX and mice
devices to quiet the X logs a bit, etc), one with "Monitor" sections to
setup their positioning for my multiple monitors on my main machine and
activate the additional modes section, and one with that "Modes" section
with extra modes for non-default resolutions. They're named accordingly,
so I can edit just the one I want if I want to change something, without
even looking at the others.

--
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

On Wed, 14 Nov 2012 16:08:27 -0500
Frank Peters <frank.peters@comcast.net> wrote:

> Also, I am not using the auto configuration but I have a custom X
> config file.

Q: What do you need the custom xconfig for?

You might find that life is easier if you remove
the xorg.conf, switch to evdev as the input, and
see what happens. If you really, really need
something you can probably just handle in your
.xinitrc or .Xdefaults. If neither of those will
work create a barebones config with "X -configure"
and add the minimum to it.

xorg.conf behaves just like an attic: it accumulates
things that noone wants to throw out becuse they
"might be useful". Taking the time to clean the
thing out -- along with your .Xdefaults, .xinitrc,
.fvwm[2]rc -- is a worthwhile part of running a
machine.

--
Steven Lembark 3646 Flora Pl
Workhorse Computing St Louis, MO 63110
lembark@wrkhors.com +1 888 359 3508

On Wed, 14 Nov 2012 16:45:27 -0500
Frank Peters <frank.peters@comcast.net> wrote:

> It's a software problem. When the keyboard stops I can immediately
> shut down X and it will be working. The hardware is not the fault.

Could be that the software is getting kicked into a lockup
state by flakey hardware returning invalid values. Be nice
if the driver would successfully reject all bad input, but
there is no guarantee that pushing white noise into it
won't put it into a locked up state.

And, yes, I've learned that the hard way :-)

--
Steven Lembark 3646 Flora Pl
Workhorse Computing St Louis, MO 63110
lembark@wrkhors.com +1 888 359 3508

On Wed, 14 Nov 2012 19:48:38 -0500
Frank Peters <frank.peters@comcast.net> wrote:

> "If it ain't broke, don't fix it."

If that were true we'd be driving Model-T's;
hell, we'd be walking.

Since you probably run something later than a
386, might have replaced your MFM or RLL drives,
might not even use a CRT any more, and probably
drive something later than a Model-T, the point
is that "keeping up" is part of managing a system.

Part of that is looking at the updated modules
that deal with modern hardware. The KB and mouse
drivers were developed in the days of dedicated
AT keyboard and mouse ports -- prior to USB with
all of its switching and shared bandwidth issues.
If you really, really, really want to use the old
drivers then find a MB with the old hardware they
were designed for and use that instead.

Otherwise you will suffer far less frustration
if you just keep up.

--
Steven Lembark 3646 Flora Pl
Workhorse Computing St Louis, MO 63110
lembark@wrkhors.com +1 888 359 3508

On Wed, 14 Nov 2012 23:25:13 -0600
Steven Lembark <lembark@wrkhors.com> wrote:

>
> ... might not even use a CRT any more,
>

I really should leave this alone but I just can't resist.

Actually, on this machine (with the keyboard problem) I still
use a CRT. The reason is that I do a lot of image processing
and I need cheap color fidelity. With an LCD, high fidelity
color comes with an equally high price, but equally proficient
CRT monitors are far less expensive. This CRT is a HUGE monster
that weighs over a hundred pounds, but for the same price I could
never find an equal LCD display.

It also uses VGA input. Think of it! Fortunately, simple
DVI-VGA adapters are still available.

>
> The KB and mouse
> drivers were developed in the days of dedicated
> AT keyboard and mouse ports -- prior to USB with
> all of its switching and shared bandwidth issues.
>

I have intended to switch to evdev, but, since things have
been working effectively -- and this is a late model Core i7
based system -- I felt no pressing need. But your argument
has convinced me to bring this task up a few notches in priority.

Frank Peters

Frank Peters posted on Wed, 14 Nov 2012 19:48:38 -0500 as excerpted:

> But if the legacy keyboard and mouse drivers have been made obsolete by
> evdev, then why are they still being distributed? Is it only to
> accommodate older systems?

Keep in mind that xorg is used on BSD systems and the like (Solaris...),
as well. I believe that's the most common use case for many of the
"legacy" drivers, including kbd and mouse but also including many of the
"exotic" graphics drivers as well -- the ones that aren't adopting RANDR,
KMS, etc, because they're running on non-linux kernels without the
required supporting infrastructure.

Not that there aren't corner-cases where kbd/mouse would be used in place
of evdev on Linux as well, but that's exactly what they are these days,
corner-cases.

Plus there's people like you who still run an old config and see little
reason to change it as long as it's working the way they want. But that
too is becoming more of a corner case, as all the various necessary
components have been out and reasonably stable for years now, so even the
slow updaters like Debian stable are standardizing on evdev now. I think
RHEL/CentOS 6 has it as well, tho those still on RHEL 5 may not, and I
think it still has a few years of support left.

--
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

Frank Peters posted on Thu, 15 Nov 2012 02:59:41 -0500 as excerpted:

> I really should leave this alone but I just can't resist.

Likewise... =;^/

> Actually, on this machine (with the keyboard problem) I still use a CRT.
> The reason is that I do a lot of image processing and I need cheap color
> fidelity. With an LCD, high fidelity color comes with an equally high
> price, but equally proficient CRT monitors are far less expensive. This
> CRT is a HUGE monster that weighs over a hundred pounds, but for the
> same price I could never find an equal LCD display.

Consider LED-backed LCDs (often simply referred to as LED rather than
LCD). They're a bit more expensive than CFL-backed LCDs (what people
normally refer to with the term LCD), but are *MUCH* more energy
efficient (makes a big difference here in Phoenix, where the AC is often
run a couple hours mid-day even in January, and most of the year you're
paying for electricity feeding the monitor twice, once to operate the
monitor, again to operate the AC to pump the heat produced back
outside)...

And more to the point for you, generally MUCH higher color fidelity.

I kind of discovered that by accident, replacing a 24-inch LCD that got
cracked with a 22-inch LED at about the same price-point a couple years
later. The LED brought out colors I never new existed on the LCD! I
don't expect to ever go back, and in fact, have been wanting to upgrade
my dual monitors to 37-42-inch (the biggest I can fit, here), but put it
off as I wasn't going to settle for LCD any longer, and dual LED monitors
at the size I wanted was simply beyond my current budget.

Of course you'll also want to be sure that they're real 8-bit-per-channel-
color, not 6-bit, which is what many of the cheap ones are, but LEDs
should /generally/ get you beyond the 6-bit-per-channel cheap range as
well. (10-bit-per-color-channel is available, but you *DO* pay thru the
nose for them! It's possible that's what you need, but perhaps not. I
know *I* was seriously surprised at the quality of the LEDs I rather
accidentally stumbled into.)

--
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

On Wed, 14 Nov 2012 23:13:30 -0600
Steven Lembark <lembark@wrkhors.com> wrote:

>
> Q: What do you need the custom xconfig for?
>
> You might find that life is easier if you remove
> the xorg.conf, switch to evdev as the input,
>

[.The following is only an innocent spiel, and is not intended
to be in any way unfriendly.]

Make life easier? Nothing could be further from the truth.

After doing some research into making the supposedly simple change
of switching to evdev, I find that I am required to:

1) Reconfigure the kernel to include many things, such as hotplug,
which I do not want or need.

2) Install and configure udev, which is a horrendous and totally
unwarranted and needless nightmare.

3) Trash my established (and simple) /dev tree

4) Get rid of module-init-tools

5) Many other ridiculous and needless tasks that are associated with all
of the above.

And for what? Just so that I can joyously sit back and watch X come
to life without a configuration file? No thank you. I'll pass.

The purpose of the edev driver, as stated in the Gentoo manual, is
only this:

"The evdev driver configures your input devices, as needed, using HAL or udev.
This allows for the X server to automatically detect the keyboard and mouse
you're using for your input devices, and removes the need to specify your
devices in xorg.conf."

I am so sorry, but I remain thoroughly unimpressed. I know exactly
what is connected to my machine. I do not require some convoluted
and barely workable user-space software scheme to figure it out for me.

What disturbs me the most, however, is this business about udev.

IMO, udev is the most twisted and unnecessary piece of cr** to have
ever been foisted upon the Linux world. It is apparently the brainchild
of the Freedesktop project, who are always busily creating more bloated
graphical extravaganzas in some misguided mission to outdo Microsoft.

I refuse to jump on that garish bandwagon. I have *real* computing
to accomplish.

For me, the appeal of Linux is that it allows the user to configure
and customize his system to suit his personal preferences, however bizarre
or unconventional those may be. The job of the Linux developers, therefore,
should be to maintain that state of openness and not to constrain
the user to any particular methodology. IOW, Linux is about *choice*
and not about conformity.

My choice is simple: absolutely no udev (or any equivalent).
If others desire to have it, then that is their choice, but
I should never be forced to follow along.

Hopefully, Gentoo has not lost this understanding and will strive
to maintain the wisdom.

Frank Peters

On Sat, Nov 17, 2012 at 1:17 PM, Frank Peters <frank.peters@comcast.net> wrote:
> On Wed, 14 Nov 2012 23:13:30 -0600
> Steven Lembark <lembark@wrkhors.com> wrote:
>
>>
>> Q: What do you need the custom xconfig for?
>>
>> You might find that life is easier if you remove
>> the xorg.conf, switch to evdev as the input,
>>
>
> [.The following is only an innocent spiel, and is not intended
> to be in any way unfriendly.]

I didn't find it unfriendly; on the contrary, quite informative.

> Make life easier? Nothing could be further from the truth.
>
> After doing some research into making the supposedly simple change
> of switching to evdev, I find that I am required to:
>
> 1) Reconfigure the kernel to include many things, such as hotplug,
> which I do not want or need.
>
> 2) Install and configure udev, which is a horrendous and totally
> unwarranted and needless nightmare.
>
> 3) Trash my established (and simple) /dev tree
>
> 4) Get rid of module-init-tools
>
> 5) Many other ridiculous and needless tasks that are associated with all
> of the above.
>
> And for what? Just so that I can joyously sit back and watch X come
> to life without a configuration file? No thank you. I'll pass.
>
> The purpose of the edev driver, as stated in the Gentoo manual, is
> only this:
>
> "The evdev driver configures your input devices, as needed, using HAL or udev.
> This allows for the X server to automatically detect the keyboard and mouse
> you're using for your input devices, and removes the need to specify your
> devices in xorg.conf."
>
> I am so sorry, but I remain thoroughly unimpressed. I know exactly
> what is connected to my machine. I do not require some convoluted
> and barely workable user-space software scheme to figure it out for me.

I do agree that if you "know exactly what is connected" to your
machine (and this never changes), udev (or mdev, or devfs for that
matter) is basically useless. Just take in mind that the majority of
users connect and disconnect stuff from their computers/tablets/phones
all the time (USB webcams, joysticks, scanners, printers; bluetooth
headphones, keyboards, phones; eSATA disks), and therefore the
developers tend to care more about that use case, which is the general
one and it contains the static one.

> What disturbs me the most, however, is this business about udev.
>
> IMO, udev is the most twisted and unnecessary piece of cr** to have
> ever been foisted upon the Linux world. It is apparently the brainchild
> of the Freedesktop project, who are always busily creating more bloated
> graphical extravaganzas in some misguided mission to outdo Microsoft.

Actually, udev was started by kernel developer Greg Kroah-Hartman.

> I refuse to jump on that garish bandwagon. I have *real* computing
> to accomplish.

All of us (I would think) have "real" computing to accomplish. That's
why many of us prefer not to worry about xorg.conf (or any other
configuration file) every time we change keyboard or mouse.

> For me, the appeal of Linux is that it allows the user to configure
> and customize his system to suit his personal preferences, however bizarre
> or unconventional those may be.

As you say, for you. For many others the appeal is different; either
because is free (as in libre), or because it gets the job done, or
because it's faster. Customization is a completely valid reason to use
Linux; it's just not the only one.

> The job of the Linux developers, therefore,
> should be to maintain that state of openness and not to constrain
> the user to any particular methodology.

With this I strongly disagree. The "job" of the developers is the one
they are being paid for, if they are being paid; and if not, their
"job" is to do whatever the hell they want to. If you are an employer
you have the right to *demand* a developer who is your employee
whatever you want. If you are just a user (like myself), you do not
have the right to *demand* anything. You can of course express your
opinion, but the devs have no obligation whatsoever to even listening
to it. If you don't like the direction of an open source project, you
have (now and forever) the freedom to choose another project, fork the
project to take it in the direction you want to (as some Gentoo devs
have recently decided to do with udev), or start contributing to the
project so it goes in the direction you believe is the correct one.

But if you are not actually writing the code or paying someone else to
do it, you don't get to tell anyone what the job of a developer is. Or
more precisely, you can say it, just don't expect the developers to
actually caring about what you (or I) have to say. They *could* care,
of course; they are just not *obligated* to.

> IOW, Linux is about *choice*
> and not about conformity.

Nobody has done anything to your freedom to choose whatever you want.
Just don't expect that someone else will do the work to maintain the
xf86-input-keyboard and xf86-input-mouse drivers; and don't expect the
X.org developers to care about them if they believe that
xf86-input-evdev is the correct answer because it works in the general
case, and they don't mind that it needs udev.

> My choice is simple: absolutely no udev (or any equivalent).
> If others desire to have it, then that is their choice, but
> I should never be forced to follow along.

Nobody is forcing anything on you (how could anyone do that?) But
someone has to maintain the code for old drivers to keep working in
new X.org releases and new kernels. Interfaces and libraries change,
and keeping up old code is work that usually nobody wants to do,
specially if it only caters to a small subset of the intended users.
You don't want to use evdev since it requires udev? That's fine; just
don't expect that someone else is going to maintain it for you.

> Hopefully, Gentoo has not lost this understanding and will strive
> to maintain the wisdom.

What wisdom?

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

On 11/17/2012 02:17 PM, Frank Peters wrote:

[trim /]

> IMO, udev is the most twisted and unnecessary piece of cr** to have
> ever been foisted upon the Linux world. It is apparently the brainchild
> of the Freedesktop project, who are always busily creating more bloated
> graphical extravaganzas in some misguided mission to outdo Microsoft.

I agree, mostly. It certainly has caused my grief.

> I refuse to jump on that garish bandwagon. I have *real* computing
> to accomplish.
>
> For me, the appeal of Linux is that it allows the user to configure
> and customize his system to suit his personal preferences, however bizarre
> or unconventional those may be. The job of the Linux developers, therefore,
> should be to maintain that state of openness and not to constrain
> the user to any particular methodology. IOW, Linux is about *choice*
> and not about conformity.

I also agree with your philosophy here. I'm not so sure that it applies
to your situation.

The kernel is the gold standard for backwards compatibility, as Linus
regularly squashes functional regressions. Freedesktop does not agree,
and probably does't have the manpower anyways. They develop new
features to work with current systems, and video driver developers
follow their lead.

> My choice is simple: absolutely no udev (or any equivalent).
> If others desire to have it, then that is their choice, but
> I should never be forced to follow along.

Well, you pointed out in your first mail that:

> My system is updated daily
^^^^^^^^^^^^^
Do you have some sort of filter on your daily updates that magically
determines whether you'll like them? If you don't want to change, don't
update. :-)

You weren't forced to update your Xorg or nvidia drivers, after all.
You chose to do so probably because you like security fixes, other bug
fixes and new features.

Did you even try to reinstall the older versions of any of your suspect
packages?

> Hopefully, Gentoo has not lost this understanding and will strive
> to maintain the wisdom.

Gentoo doesn't control the software you are b**ching about, so I don't
know what you expect to happen here.

Again, I applaud your philosophical position, but I *like* being able to
unplug and replug keyboards and mice without worry. I'm not inclined to
fork Xorg, so I've sucked it up and joined the udev/evdev world. I'll
pick another hill to die on.

I used to hate initramfs boot sequences, too. I was horrified when the
linux raid maintainer declared that new features were only going to be
supported in initramfs systems. When some disk hot-swap features I
wanted pushed me that way, I didn't fork the kernel. I learned how
early userspace worked and switched. Now I like it. You might find the
same happens to you when you try evdev.

HTH,

Phil

On Sat, 17 Nov 2012 18:21:01 -0500
Phil Turmel <philip@turmel.org> wrote:

>
> I'm not inclined to
> fork Xorg, so I've sucked it up and joined the udev/evdev world.
>

The problem was a faulty keyboard. In retrospect it would seem obvious,
but the fact that I could regain control by stopping X and the fact that
there were other recent reports of identical issues prompted me to
make a post to this list. For example, see the following link:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/1066189

For the time being I can keep using my "antiquated" input drivers, but
eventually I will be forced to adapt by switching to evdev.

Yes, *forced*. The freedom of choice is slowly being removed. We are
moving toward, a monolithic, one-size-fits-all, Linux.

Let's consider a case in point from the Gentoo portage tree.

I have lots of ebooks in DJVU format, and I really can appreciate the
excellent DJVU reader called djview. However, the latest update of
djview came as quite a surprise. Apparently, dbus is now required
by Gentoo to build the djview-4.9 package and there is no way to avoid
it. My make.conf file has "-dbus" indicated but that means nothing.
Choice? What choice? No dbus, no djview.

Fortunately, I can compile the djview package myself outside of Gentoo
without using dbus, but the case illustrates the fact that even though
certain options are available these options are being withheld by
the distributors.

Most Linux users probably could not care less about such things, but,
for me, the issue of choice is much more than just a philosophical rant.
It has significant practical consequences as well, but a discussion
of those would be too far off topic.

Thanks to all those who offered advice.

Frank Peters

On 19/11/12 02:13, Frank Peters wrote:
> Let's consider a case in point from the Gentoo portage tree.
>
> I have lots of ebooks in DJVU format, and I really can appreciate the
> excellent DJVU reader called djview. However, the latest update of
> djview came as quite a surprise. Apparently, dbus is now required
> by Gentoo to build the djview-4.9 package and there is no way to avoid
> it. My make.conf file has "-dbus" indicated but that means nothing.
> Choice? What choice? No dbus, no djview.
>
> Fortunately, I can compile the djview package myself outside of Gentoo
> without using dbus, but the case illustrates the fact that even though
> certain options are available these options are being withheld by
> the distributors.

This would be worthy of a bug report, or at least a discussion with the
maintainer. He may not be aware that dbus is not required, or have some
logic as to why it has been set as a requirement. If I was in this
position and couldn't get the official ebuild modified, I would make a
customised ebuild in my local overlay and compile it inside portage but
with my ebuild. At least this keeps the system consistent.

--
Linux since 1996, Gentoo since 2004