Gentoo Archives: gentoo-amd64

From: "Canek Peláez Valdés" <caneko@×××××.com>
To: gentoo-amd64@l.g.o
Subject: Re: [gentoo-amd64] Keyboard Stops Working Under X
Date: Sun, 18 Nov 2012 00:03:24
Message-Id: CADPrc811WhU+w-K5fzXcXCC9yyV3kmhvgS7DW5uNmof=KSdOHg@mail.gmail.com
In Reply to: Re: [gentoo-amd64] Keyboard Stops Working Under X by Frank Peters
1 On Sat, Nov 17, 2012 at 1:17 PM, Frank Peters <frank.peters@×××××××.net> wrote:
2 > On Wed, 14 Nov 2012 23:13:30 -0600
3 > Steven Lembark <lembark@×××××××.com> wrote:
4 >
5 >>
6 >> Q: What do you need the custom xconfig for?
7 >>
8 >> You might find that life is easier if you remove
9 >> the xorg.conf, switch to evdev as the input,
10 >>
11 >
12 > [The following is only an innocent spiel, and is not intended
13 > to be in any way unfriendly.]
14
15 I didn't find it unfriendly; on the contrary, quite informative.
16
17 > Make life easier? Nothing could be further from the truth.
18 >
19 > After doing some research into making the supposedly simple change
20 > of switching to evdev, I find that I am required to:
21 >
22 > 1) Reconfigure the kernel to include many things, such as hotplug,
23 > which I do not want or need.
24 >
25 > 2) Install and configure udev, which is a horrendous and totally
26 > unwarranted and needless nightmare.
27 >
28 > 3) Trash my established (and simple) /dev tree
29 >
30 > 4) Get rid of module-init-tools
31 >
32 > 5) Many other ridiculous and needless tasks that are associated with all
33 > of the above.
34 >
35 > And for what? Just so that I can joyously sit back and watch X come
36 > to life without a configuration file? No thank you. I'll pass.
37 >
38 > The purpose of the edev driver, as stated in the Gentoo manual, is
39 > only this:
40 >
41 > "The evdev driver configures your input devices, as needed, using HAL or udev.
42 > This allows for the X server to automatically detect the keyboard and mouse
43 > you're using for your input devices, and removes the need to specify your
44 > devices in xorg.conf."
45 >
46 > I am so sorry, but I remain thoroughly unimpressed. I know exactly
47 > what is connected to my machine. I do not require some convoluted
48 > and barely workable user-space software scheme to figure it out for me.
49
50 I do agree that if you "know exactly what is connected" to your
51 machine (and this never changes), udev (or mdev, or devfs for that
52 matter) is basically useless. Just take in mind that the majority of
53 users connect and disconnect stuff from their computers/tablets/phones
54 all the time (USB webcams, joysticks, scanners, printers; bluetooth
55 headphones, keyboards, phones; eSATA disks), and therefore the
56 developers tend to care more about that use case, which is the general
57 one and it contains the static one.
58
59 > What disturbs me the most, however, is this business about udev.
60 >
61 > IMO, udev is the most twisted and unnecessary piece of cr** to have
62 > ever been foisted upon the Linux world. It is apparently the brainchild
63 > of the Freedesktop project, who are always busily creating more bloated
64 > graphical extravaganzas in some misguided mission to outdo Microsoft.
65
66 Actually, udev was started by kernel developer Greg Kroah-Hartman.
67
68 > I refuse to jump on that garish bandwagon. I have *real* computing
69 > to accomplish.
70
71 All of us (I would think) have "real" computing to accomplish. That's
72 why many of us prefer not to worry about xorg.conf (or any other
73 configuration file) every time we change keyboard or mouse.
74
75 > For me, the appeal of Linux is that it allows the user to configure
76 > and customize his system to suit his personal preferences, however bizarre
77 > or unconventional those may be.
78
79 As you say, for you. For many others the appeal is different; either
80 because is free (as in libre), or because it gets the job done, or
81 because it's faster. Customization is a completely valid reason to use
82 Linux; it's just not the only one.
83
84 > The job of the Linux developers, therefore,
85 > should be to maintain that state of openness and not to constrain
86 > the user to any particular methodology.
87
88 With this I strongly disagree. The "job" of the developers is the one
89 they are being paid for, if they are being paid; and if not, their
90 "job" is to do whatever the hell they want to. If you are an employer
91 you have the right to *demand* a developer who is your employee
92 whatever you want. If you are just a user (like myself), you do not
93 have the right to *demand* anything. You can of course express your
94 opinion, but the devs have no obligation whatsoever to even listening
95 to it. If you don't like the direction of an open source project, you
96 have (now and forever) the freedom to choose another project, fork the
97 project to take it in the direction you want to (as some Gentoo devs
98 have recently decided to do with udev), or start contributing to the
99 project so it goes in the direction you believe is the correct one.
100
101 But if you are not actually writing the code or paying someone else to
102 do it, you don't get to tell anyone what the job of a developer is. Or
103 more precisely, you can say it, just don't expect the developers to
104 actually caring about what you (or I) have to say. They *could* care,
105 of course; they are just not *obligated* to.
106
107 > IOW, Linux is about *choice*
108 > and not about conformity.
109
110 Nobody has done anything to your freedom to choose whatever you want.
111 Just don't expect that someone else will do the work to maintain the
112 xf86-input-keyboard and xf86-input-mouse drivers; and don't expect the
113 X.org developers to care about them if they believe that
114 xf86-input-evdev is the correct answer because it works in the general
115 case, and they don't mind that it needs udev.
116
117 > My choice is simple: absolutely no udev (or any equivalent).
118 > If others desire to have it, then that is their choice, but
119 > I should never be forced to follow along.
120
121 Nobody is forcing anything on you (how could anyone do that?) But
122 someone has to maintain the code for old drivers to keep working in
123 new X.org releases and new kernels. Interfaces and libraries change,
124 and keeping up old code is work that usually nobody wants to do,
125 specially if it only caters to a small subset of the intended users.
126 You don't want to use evdev since it requires udev? That's fine; just
127 don't expect that someone else is going to maintain it for you.
128
129 > Hopefully, Gentoo has not lost this understanding and will strive
130 > to maintain the wisdom.
131
132 What wisdom?
133
134 Regards.
135 --
136 Canek Peláez Valdés
137 Posgrado en Ciencia e Ingeniería de la Computación
138 Universidad Nacional Autónoma de México