Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Sonntag 17 Mai 2009, Alan McKinnon wrote: > On Sunday 17 May 2009 03:33:22 pk wrote: > > Alan McKinnon wrote: > > > As I see it, at the bottom of the stack you have a kernel and at the > > > top a user space app (the X server will do for an example). Plug in a > > > USB device that the app can use, and the kernel needs to make a node in > > > /dev for it if it's not already there. The kernel should not be > > > interrogating the device for all possible info - that is expensive - > > > and doesn't need to. It only needs enough info to know what driver, > > > major and minor numbers to use. X OTOH, can > > > > I couldn't agree more. And this is what Udev, as a user space app, does. > > The only thing it doesn't handle is communicating with other user space > > apps; this is currently Hals job. > > > > > the current model uses udev as the interface to the kernel's nodes and > > > HAL as the interface to exactly what hardware you have. Seems pretty > > > sane for the most usual use case. At some point in the stack you will > > > need the OS-dependant part, my guess is the best place is between hal > > > and udev. Only Linux uses > > > > Well, as I understand it this is what it looks like today: > > > > kernel <-> udev (or equivalent for non-linux kernel/OS) <-> hal <-> dbus > > <-> user apps > > > > To me that seems a bit redundant... > > No, there's nothing redundant in that. udev talks kernel-speak, hal talks > userspace-speak. Hal could be distro-agnostic, udev can't be (not in a sane > environment) and dbus is simply a transport layer for messages. That's five > different functions going on, and none of them logically belong with any > other in the same layer. > > > What I would like to see: > > > > kernel <-> udev <-> user apps > > Then X must talk to udev directly. Two problems: > > - only Linux has udev. Other OSes may not need, want or be willing to touch > udev with a bargepole. > - X is multi-platform. Good luck getting Keith to agree to make it > essentially Linux only :-) which is not a problem at all. udev only creates device nodes. There is no need to 'talk udev' or do special crap for udev. > > > Yes, but if the developers could agree on a common API for the udev > > daemon and it's equivalents on other platforms (what does BSD use?)... and there already is one. It is called '/dev'
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
Mark Knecht wrote: > > Dale, >As far as I can tell I'm not having any problems. This machine was > using a 2.6.28 kernel up until yesterday when I updated to 2.6.29-r4. > The point I'm trying to make is that this old driver and all the > kernels I have used up to now have all worked. > >I noticed that the machine does have the older C compile 4.1.2 on > it and that's what most of the machine has been built with. I'm just > starting to switch over to 4.3.2 which is why it's selected. This > kernel and the version of nvidia-drivers I listed earlier compile on > both for me. The one I used for this kernel/driver combo was 4.3.2/ > > gandalf ~ # gcc-config -l > [1] i686-pc-linux-gnu-4.1.2 > [2] i686-pc-linux-gnu-4.3.2 * > gandalf ~ # > >The VGA is older I think. 440 series. I suspect it's the one I put > in 5-6 years ago. I don't remember whether we ever updated it: > > gandalf ~ # lspci | grep VGA > 03:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 > MX 440 AGP 8x] (rev a2) > gandalf ~ # > >In my case attempting to install anything newer results in a big > emerge message telling me not to and suggesting this specific nvdia > driver. > > gandalf ~ # lsmod > Module Size Used by > usblp 10140 0 > uhci_hcd 18980 0 > sbp2 19184 1 > usbhid 21468 2 > nvidia 4699324 0 > i2c_nforce2 5828 0 > ohci_hcd 20080 0 > snd_intel8x0 25784 0 > nvidia_agp 5704 1 > snd_ac97_codec 90232 1 snd_intel8x0 > ac97_bus1316 1 snd_ac97_codec > agpgart25748 2 nvidia,nvidia_agp > i2c_core 17564 2 nvidia,i2c_nforce2 > ohci1394 25664 1 > ehci_hcd 29380 0 > ieee1394 66064 2 sbp2,ohci1394 > gandalf ~ # > > > gandalf ~ # modinfo nvidia > filename: /lib/modules/2.6.29-gentoo-r4/video/nvidia.ko > license:NVIDIA > alias: char-major-195-* > alias: pci:v10DEd*sv*sd*bc03sc02i00* > alias: pci:v10DEd*sv*sd*bc03sc00i00* > depends:agpgart,i2c-core > vermagic: 2.6.29-gentoo-r4 preempt mod_unload K7 > parm: NVreg_VideoMemoryTypeOverride:int > parm: NVreg_EnableVia4x:int > parm: NVreg_EnableALiAGP:int > parm: NVreg_ReqAGPRate:int > parm: NVreg_NvAGP:int > parm: NVreg_EnableAGPSBA:int > parm: NVreg_EnableAGPFW:int > parm: NVreg_SoftEDIDs:int > parm: NVreg_Mobile:int > parm: NVreg_ModifyDeviceFiles:int > parm: NVreg_DeviceFileUID:int > parm: NVreg_DeviceFileGID:int > parm: NVreg_DeviceFileMode:int > parm: NVreg_ResmanDebugLevel:int > parm: NVreg_FlatPanelMode:int > parm: NVreg_DevicesConnected:int > parm: NVreg_RmLogonRC:int > parm: NVreg_RemapLimit:int > parm: NVreg_UpdateMemoryTypes:int > parm: NVreg_DetectPrimaryVga:int > parm: NVreg_RegistryDwords:charp > parm: NVreg_VbiosFromROM:int > parm: NVreg_EnableBrightnessControl:int > parm: NVreg_PanelPWMFrequency:int > parm: NVreg_PanelBrightnessLimits:int > parm: NVreg_RMEdgeIntrCheck:int > parm: NVreg_UsePageAttributeTable:int > parm: NVreg_MapRegistersEarly:int > gandalf ~ # > > - Mark > > > I suspect that this is a difference between our drivers. Yours will build with the newer kernels where mine doesn't for some reason. I did google the error and it is reported by a lot of others as well. I can't recall the exact error at the moment but it couldn't find something to do with the kernel. What I read was that something moved that nvidia looks for during the install. Now that I have upgraded a bit, I may give some other versions a try again. I'm going to try the ones I already have downloaded tho. It takes hours to download anything on dial-up. Dale :-) :-)
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Sun, May 17, 2009 at 12:12 PM, Dale wrote: > Mark Knecht wrote: >> On Sun, May 17, 2009 at 11:00 AM, Alan McKinnon >> wrote: >> >>> On Sunday 17 May 2009 19:10:05 bn wrote: >>> Dale ha scritto: > I hope someone wins the debate soon and gets this to work and be "user > friendly". I'm about to make a fresh backup and try this again. I have > upgraded my kernel to a really new version, 2.6.25. Sorry, nvidia won't > compile with anything newer that I have tried. > Uh? last nvidia-drivers needs 2.6.25 kernel? >>> Dale has an old video card and needs one of the nvidia legacy driver >>> releases. >>> He finds that that release doesn't work with kernels after .25 >>> >> >> Hummnow I'm getting interested. I just did an emerge -DuN world to >> my dad's machine in Southern California last night. He's got a 6 year >> old machine with an old nvidia card that's no longer supported by the >> newest drivers so the emerge messages tell me that I have to use an >> older legacy version of the driver. Thing is I have him on >> gentoo-sources-2.6.29-r4 using nvidia-drivers-96.43.09. Everything >> seems to be working from here. I see the driver in memory. I Can run X >> apps remotely. >> >> gandalf ~ # uname -a >> Linux gandalf 2.6.29-gentoo-r4 #3 PREEMPT Sun May 17 06:58:58 PDT 2009 >> i686 AMD Athlon(tm) XP 2500+ AuthenticAMD GNU/Linux >> gandalf ~ # >> >> gandalf ~ # emerge -pv nvidia-drivers >> >> These are the packages that would be merged, in order: >> >> Calculating dependencies... done! >> [ebuild R ] x11-drivers/nvidia-drivers-96.43.09 USE="acpi gtk >> -custom-cflags (-multilib)" 0 kB >> >> Total: 1 package (1 reinstall), Size of downloads: 0 kB >> gandalf ~ # >> >> I guess my question is whether he's going to have issues. He's really >> bad about reporting this stuff to me and I'm not there to see the >> screen or use the system. >> >> I don't see much in /var/log/Xorg.0.log other than a complaint about >> GLX and freetype. freetype I can fix. GLX I haven't looked into. >> >> Any problems? >> >> Thanks, >> Mark >> >> >> > > Hey, we got a pretty similar rig here. I have a FX5200, made by > Chaintech I think. Info alert: > > r...@smoker / # uname -a > Linux smoker 2.6.25-gentoo-r9 #3 PREEMPT Sat May 16 12:06:51 CDT 2009 > i686 AMD Athlon(tm) XP 2500+ AuthenticAMD GNU/Linux > r...@smoker / # emerge -pv nvidia-drivers > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild R ] x11-drivers/nvidia-drivers-173.14.09 USE="acpi gtk > -custom-cflags (-multilib)" 0 kB > > Total: 1 package (1 reinstall), Size of downloads: 0 kB > r...@smoker / # lspci | grep VGA > 02:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX > 5200] (rev a1) > r...@smoker / # > > My drivers appears to be a little newer but you may have a older card > than me. If so, my sympathies. ;-) There is a newer version of the > 173.* series but it wouldn't compile either. I think this is the only > version that works. That goodness it does a good job. > > Dale Dale, As far as I can tell I'm not having any problems. This machine was using a 2.6.28 kernel up until yesterday when I updated to 2.6.29-r4. The point I'm trying to make is that this old driver and all the kernels I have used up to now have all worked. I noticed that the machine does have the older C compile 4.1.2 on it and that's what most of the machine has been built with. I'm just starting to switch over to 4.3.2 which is why it's selected. This kernel and the version of nvidia-drivers I listed earlier compile on both for me. The one I used for this kernel/driver combo was 4.3.2/ gandalf ~ # gcc-config -l [1] i686-pc-linux-gnu-4.1.2 [2] i686-pc-linux-gnu-4.3.2 * gandalf ~ # The VGA is older I think. 440 series. I suspect it's the one I put in 5-6 years ago. I don't remember whether we ever updated it: gandalf ~ # lspci | grep VGA 03:00.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev a2) gandalf ~ # In my case attempting to install anything newer results in a big emerge message telling me not to and suggesting this specific nvdia driver. gandalf ~ # lsmod Module Size Used by usblp 10140 0 uhci_hcd 18980 0 sbp2 19184 1 usbhid 21468 2 nvidia 4699324 0 i2c_nforce2 5828 0 ohci_hcd 20080 0 snd_intel8x0 25784 0 nvidia_agp 5704 1 snd_ac97_codec 90232 1 snd_intel8x0 ac97_bus1316 1 snd_ac97_codec agpgart25748 2 nvidia,nvidia_agp i2c_core 17564 2 nvidia,i2c_nforce2 ohci1394 25664 1 ehci_hcd 29380 0 ieee1394 66064 2 sbp2,ohci1394 gandalf ~ # gandalf ~ # modinfo nvidia filename: /lib/modules/2.6.29-gentoo-r4/video/nvidia.ko license:NVIDIA alias:
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
Mark Knecht wrote: > On Sun, May 17, 2009 at 11:00 AM, Alan McKinnon > wrote: > >> On Sunday 17 May 2009 19:10:05 bn wrote: >> >>> Dale ha scritto: >>> I hope someone wins the debate soon and gets this to work and be "user friendly". I'm about to make a fresh backup and try this again. I have upgraded my kernel to a really new version, 2.6.25. Sorry, nvidia won't compile with anything newer that I have tried. >>> Uh? last nvidia-drivers needs 2.6.25 kernel? >>> >> Dale has an old video card and needs one of the nvidia legacy driver >> releases. >> He finds that that release doesn't work with kernels after .25 >> > > Hummnow I'm getting interested. I just did an emerge -DuN world to > my dad's machine in Southern California last night. He's got a 6 year > old machine with an old nvidia card that's no longer supported by the > newest drivers so the emerge messages tell me that I have to use an > older legacy version of the driver. Thing is I have him on > gentoo-sources-2.6.29-r4 using nvidia-drivers-96.43.09. Everything > seems to be working from here. I see the driver in memory. I Can run X > apps remotely. > > gandalf ~ # uname -a > Linux gandalf 2.6.29-gentoo-r4 #3 PREEMPT Sun May 17 06:58:58 PDT 2009 > i686 AMD Athlon(tm) XP 2500+ AuthenticAMD GNU/Linux > gandalf ~ # > > gandalf ~ # emerge -pv nvidia-drivers > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild R ] x11-drivers/nvidia-drivers-96.43.09 USE="acpi gtk > -custom-cflags (-multilib)" 0 kB > > Total: 1 package (1 reinstall), Size of downloads: 0 kB > gandalf ~ # > > I guess my question is whether he's going to have issues. He's really > bad about reporting this stuff to me and I'm not there to see the > screen or use the system. > > I don't see much in /var/log/Xorg.0.log other than a complaint about > GLX and freetype. freetype I can fix. GLX I haven't looked into. > > Any problems? > > Thanks, > Mark > > > Hey, we got a pretty similar rig here. I have a FX5200, made by Chaintech I think. Info alert: r...@smoker / # uname -a Linux smoker 2.6.25-gentoo-r9 #3 PREEMPT Sat May 16 12:06:51 CDT 2009 i686 AMD Athlon(tm) XP 2500+ AuthenticAMD GNU/Linux r...@smoker / # emerge -pv nvidia-drivers These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-drivers/nvidia-drivers-173.14.09 USE="acpi gtk -custom-cflags (-multilib)" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB r...@smoker / # lspci | grep VGA 02:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1) r...@smoker / # My drivers appears to be a little newer but you may have a older card than me. If so, my sympathies. ;-) There is a newer version of the 173.* series but it wouldn't compile either. I think this is the only version that works. That goodness it does a good job. Dale :-) :-)
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
bn wrote: > Dale ha scritto: > > >> I hope someone wins the debate soon and gets this to work and be "user >> friendly". I'm about to make a fresh backup and try this again. I have >> upgraded my kernel to a really new version, 2.6.25. Sorry, nvidia won't >> compile with anything newer that I have tried. >> > > Uh? last nvidia-drivers needs 2.6.25 kernel? > > m. > > > Well, I have a old card so I have to use a old driver but I can't get any of the 2.6.29 kernels to get along with nvidia at all. It barely does even try to compile. It's not just me this time either. Google reports that others are having the same issue. I did get my 2.6.25 kernel to work and nvidia to compile. Now to try out this xorg upgrade. Got to update my backups first tho. Not in no real big hurry either. I suspect it won't be any better than the last time. :/ Dale :-) :-)
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Sun, May 17, 2009 at 11:00 AM, Alan McKinnon wrote: > On Sunday 17 May 2009 19:10:05 bn wrote: >> Dale ha scritto: >> > I hope someone wins the debate soon and gets this to work and be "user >> > friendly". I'm about to make a fresh backup and try this again. I have >> > upgraded my kernel to a really new version, 2.6.25. Sorry, nvidia won't >> > compile with anything newer that I have tried. >> >> Uh? last nvidia-drivers needs 2.6.25 kernel? > > Dale has an old video card and needs one of the nvidia legacy driver releases. > He finds that that release doesn't work with kernels after .25 Hummnow I'm getting interested. I just did an emerge -DuN world to my dad's machine in Southern California last night. He's got a 6 year old machine with an old nvidia card that's no longer supported by the newest drivers so the emerge messages tell me that I have to use an older legacy version of the driver. Thing is I have him on gentoo-sources-2.6.29-r4 using nvidia-drivers-96.43.09. Everything seems to be working from here. I see the driver in memory. I Can run X apps remotely. gandalf ~ # uname -a Linux gandalf 2.6.29-gentoo-r4 #3 PREEMPT Sun May 17 06:58:58 PDT 2009 i686 AMD Athlon(tm) XP 2500+ AuthenticAMD GNU/Linux gandalf ~ # gandalf ~ # emerge -pv nvidia-drivers These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-drivers/nvidia-drivers-96.43.09 USE="acpi gtk -custom-cflags (-multilib)" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB gandalf ~ # I guess my question is whether he's going to have issues. He's really bad about reporting this stuff to me and I'm not there to see the screen or use the system. I don't see much in /var/log/Xorg.0.log other than a complaint about GLX and freetype. freetype I can fix. GLX I haven't looked into. Any problems? Thanks, Mark
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
Alan McKinnon ha scritto: > On Sunday 17 May 2009 19:10:05 bn wrote: >> Dale ha scritto: >>> I hope someone wins the debate soon and gets this to work and be "user >>> friendly". I'm about to make a fresh backup and try this again. I have >>> upgraded my kernel to a really new version, 2.6.25. Sorry, nvidia won't >>> compile with anything newer that I have tried. >> Uh? last nvidia-drivers needs 2.6.25 kernel? > > Dale has an old video card and needs one of the nvidia legacy driver > releases. > He finds that that release doesn't work with kernels after .25 > Uh, I see. I was worried, sorry. m.
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Sunday 17 May 2009 19:10:05 bn wrote: > Dale ha scritto: > > I hope someone wins the debate soon and gets this to work and be "user > > friendly". I'm about to make a fresh backup and try this again. I have > > upgraded my kernel to a really new version, 2.6.25. Sorry, nvidia won't > > compile with anything newer that I have tried. > > Uh? last nvidia-drivers needs 2.6.25 kernel? Dale has an old video card and needs one of the nvidia legacy driver releases. He finds that that release doesn't work with kernels after .25 -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
Dale ha scritto: > I hope someone wins the debate soon and gets this to work and be "user > friendly". I'm about to make a fresh backup and try this again. I have > upgraded my kernel to a really new version, 2.6.25. Sorry, nvidia won't > compile with anything newer that I have tried. Uh? last nvidia-drivers needs 2.6.25 kernel? m.
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Sunday 17 May 2009 14:15:31 pk wrote: > > But you have that in the current setup. Hal (for better or worse) is the > > daemon. dbus is simply a message transport and can be omitted from the > > conceptual diagram > > Why is dbus needed? Why can't the user space apps talk to the user space > daemon directly? To me it's just another unnecessary layer, each layer > needs some kind of translation and thus resources. To me hal or whatever > may replace it should have a minimalist approach. Because the methodology is not that user-space apps talk to hal, but that hal sends events to user space apps that are listening. And hal does not and should not know anything about those apps. Polling vs events is a problem that was solved a very long time ago. For a dynamically changing system, events wins hands down almost always (one major exception - real time OSes). It's asynchronous, easier to program and both hal and the user space app talk to one and only one well defined API, and just forget all about timing issues. From an engineering point of view, a message bus is an excellent idea. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
Alan McKinnon wrote: > - only Linux has udev. Other OSes may not need, want or be willing to touch > udev with a bargepole. Yes, udev is linux only. Replace udev with whatever is available on other platforms in that diagram. I just used linux as an example... Sorry for not making it clear. > But you have that in the current setup. Hal (for better or worse) is the > daemon. dbus is simply a message transport and can be omitted from the > conceptual diagram Why is dbus needed? Why can't the user space apps talk to the user space daemon directly? To me it's just another unnecessary layer, each layer needs some kind of translation and thus resources. To me hal or whatever may replace it should have a minimalist approach. > You could be forced to use Windows... Well, the way I see it, some people/projects are aiming to create a new "Windows". But I'm doing a "don Quijote" here... Best regards Peter K
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Sunday 17 May 2009 03:33:22 pk wrote: > Alan McKinnon wrote: > > As I see it, at the bottom of the stack you have a kernel and at the top > > a user space app (the X server will do for an example). Plug in a USB > > device that the app can use, and the kernel needs to make a node in /dev > > for it if it's not already there. The kernel should not be interrogating > > the device for all possible info - that is expensive - and doesn't need > > to. It only needs enough info to know what driver, major and minor > > numbers to use. X OTOH, can > > I couldn't agree more. And this is what Udev, as a user space app, does. > The only thing it doesn't handle is communicating with other user space > apps; this is currently Hals job. > > > the current model uses udev as the interface to the kernel's nodes and > > HAL as the interface to exactly what hardware you have. Seems pretty sane > > for the most usual use case. At some point in the stack you will need the > > OS-dependant part, my guess is the best place is between hal and udev. > > Only Linux uses > > Well, as I understand it this is what it looks like today: > > kernel <-> udev (or equivalent for non-linux kernel/OS) <-> hal <-> dbus > <-> user apps > > To me that seems a bit redundant... No, there's nothing redundant in that. udev talks kernel-speak, hal talks userspace-speak. Hal could be distro-agnostic, udev can't be (not in a sane environment) and dbus is simply a transport layer for messages. That's five different functions going on, and none of them logically belong with any other in the same layer. > What I would like to see: > > kernel <-> udev <-> user apps Then X must talk to udev directly. Two problems: - only Linux has udev. Other OSes may not need, want or be willing to touch udev with a bargepole. - X is multi-platform. Good luck getting Keith to agree to make it essentially Linux only :-) > Or at the most: > > kernel <-> udev <-> daemon <-> user apps. But you have that in the current setup. Hal (for better or worse) is the daemon. dbus is simply a message transport and can be omitted from the conceptual diagram > > udev, but all OSes use something in that spot. And if not, they have > > static nodes. > > Yes, but if the developers could agree on a common API for the udev > daemon and it's equivalents on other platforms (what does BSD use?)... > Or if they could agree on using "Hal v2" (rewritten from scratch with no > or a minimum of dependencies). I don't think that's feasible. Easiest would be the bottom layer of hal has OS-specific code to talk to udev (or it's equivalent in other OSes). Or perhaps a plugin/module type system. > > Meanwhile we have an acknowledged problem with hal - it's too complex, > > too many things have been shoved into it that were never catered for in > > the design, configuration is horrific - and the devs are having their > > usual spirited debate about how best to approach a solution. This is > > perfectly normal and perfectly healthy > > Yes, I guess so. Since I'm (currently) not in the position to help out > I'll have to live with whatever they come up with. But sometimes it's a > bit frustrating... Sorry for the ranting. Hey, it could be worse. You could be forced to use Windows... -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
Alan McKinnon wrote: > As I see it, at the bottom of the stack you have a kernel and at the top a > user space app (the X server will do for an example). Plug in a USB device > that the app can use, and the kernel needs to make a node in /dev for it if > it's not already there. The kernel should not be interrogating the device for > all possible info - that is expensive - and doesn't need to. It only needs > enough info to know what driver, major and minor numbers to use. X OTOH, can I couldn't agree more. And this is what Udev, as a user space app, does. The only thing it doesn't handle is communicating with other user space apps; this is currently Hals job. > the current model uses udev as the interface to the kernel's nodes and HAL as > the interface to exactly what hardware you have. Seems pretty sane for the > most usual use case. At some point in the stack you will need the > OS-dependant > part, my guess is the best place is between hal and udev. Only Linux uses Well, as I understand it this is what it looks like today: kernel <-> udev (or equivalent for non-linux kernel/OS) <-> hal <-> dbus <-> user apps To me that seems a bit redundant... What I would like to see: kernel <-> udev <-> user apps Or at the most: kernel <-> udev <-> daemon <-> user apps. > udev, but all OSes use something in that spot. And if not, they have static > nodes. Yes, but if the developers could agree on a common API for the udev daemon and it's equivalents on other platforms (what does BSD use?)... Or if they could agree on using "Hal v2" (rewritten from scratch with no or a minimum of dependencies). > Meanwhile we have an acknowledged problem with hal - it's too complex, too > many things have been shoved into it that were never catered for in the > design, configuration is horrific - and the devs are having their usual > spirited debate about how best to approach a solution. This is perfectly > normal and perfectly healthy Yes, I guess so. Since I'm (currently) not in the position to help out I'll have to live with whatever they come up with. But sometimes it's a bit frustrating... Sorry for the ranting. Best regards Peter K
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
Alan McKinnon wrote: > On Saturday 16 May 2009 19:14:17 pk wrote: > >> Alan McKinnon wrote: >> >>> I'm not sure who's criticizing DeviceKit, but it isn't me :-) >>> >> I guess it was me... :-) >> >> I find this thread interesting: >> http://lists.freedesktop.org/archives/xorg/2009-May/045561.html >> >> ...especially this: >> http://lists.freedesktop.org/archives/xorg/2009-May/045574.html >> >> Which seems like a much more sane way... to me. I don't know what BSD >> and other platforms use (instead of Udev) but I'm sure one could come up >> with a common API. >> > > Sometimes you have to make several horrendous errors to know what to not do > and thereby deduce what you should do - the only version 3 rule of thumb :-) > > From threads involving the hal maintainers I get the idea that the problem is > not so much the idea of hal, but rather it's implementation. And then there's > those fdi files... > > As I see it, at the bottom of the stack you have a kernel and at the top a > user space app (the X server will do for an example). Plug in a USB device > that the app can use, and the kernel needs to make a node in /dev for it if > it's not already there. The kernel should not be interrogating the device for > all possible info - that is expensive - and doesn't need to. It only needs > enough info to know what driver, major and minor numbers to use. X OTOH, can > successfully use much more info. If you have a 19 button mouse, it would like > to know and could even use it as a one-handed keyboard (extreme example). So > the current model uses udev as the interface to the kernel's nodes and HAL as > the interface to exactly what hardware you have. Seems pretty sane for the > most usual use case. At some point in the stack you will need the > OS-dependant > part, my guess is the best place is between hal and udev. Only Linux uses > udev, but all OSes use something in that spot. And if not, they have static > nodes. > > Meanwhile we have an acknowledged problem with hal - it's too complex, too > many things have been shoved into it that were never catered for in the > design, configuration is horrific - and the devs are having their usual > spirited debate about how best to approach a solution. This is perfectly > normal and perfectly healthy > > I hope someone wins the debate soon and gets this to work and be "user friendly". I'm about to make a fresh backup and try this again. I have upgraded my kernel to a really new version, 2.6.25. Sorry, nvidia won't compile with anything newer that I have tried. If it don't work this time, this could end up a with permanent -hal for xorg-server. I quite happy with the way my box works now anyway. ;-) Just trying to keep up with the times I guess. < Dale crosses fingers and toes to > Dale :-) :-)
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Saturday 16 May 2009 19:14:17 pk wrote: > Alan McKinnon wrote: > > I'm not sure who's criticizing DeviceKit, but it isn't me :-) > > I guess it was me... :-) > > I find this thread interesting: > http://lists.freedesktop.org/archives/xorg/2009-May/045561.html > > ...especially this: > http://lists.freedesktop.org/archives/xorg/2009-May/045574.html > > Which seems like a much more sane way... to me. I don't know what BSD > and other platforms use (instead of Udev) but I'm sure one could come up > with a common API. Sometimes you have to make several horrendous errors to know what to not do and thereby deduce what you should do - the only version 3 rule of thumb :-) From threads involving the hal maintainers I get the idea that the problem is not so much the idea of hal, but rather it's implementation. And then there's those fdi files... As I see it, at the bottom of the stack you have a kernel and at the top a user space app (the X server will do for an example). Plug in a USB device that the app can use, and the kernel needs to make a node in /dev for it if it's not already there. The kernel should not be interrogating the device for all possible info - that is expensive - and doesn't need to. It only needs enough info to know what driver, major and minor numbers to use. X OTOH, can successfully use much more info. If you have a 19 button mouse, it would like to know and could even use it as a one-handed keyboard (extreme example). So the current model uses udev as the interface to the kernel's nodes and HAL as the interface to exactly what hardware you have. Seems pretty sane for the most usual use case. At some point in the stack you will need the OS-dependant part, my guess is the best place is between hal and udev. Only Linux uses udev, but all OSes use something in that spot. And if not, they have static nodes. Meanwhile we have an acknowledged problem with hal - it's too complex, too many things have been shoved into it that were never catered for in the design, configuration is horrific - and the devs are having their usual spirited debate about how best to approach a solution. This is perfectly normal and perfectly healthy -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
Alan McKinnon wrote: > I'm not sure who's criticizing DeviceKit, but it isn't me :-) I guess it was me... :-) I find this thread interesting: http://lists.freedesktop.org/archives/xorg/2009-May/045561.html ...especially this: http://lists.freedesktop.org/archives/xorg/2009-May/045574.html Which seems like a much more sane way... to me. I don't know what BSD and other platforms use (instead of Udev) but I'm sure one could come up with a common API. Mvh Peter K
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Friday 15 May 2009, Tony Davison wrote: > On Tuesday 07 April 2009 12:25:07 Volker Armin Hemmann wrote: > > On Tuesday 07 April 2009, Alan McKinnon wrote: > > > Is so OBVIOUSLY the correct way to go, and so OBVIOUSLY much easier. > > > Right? I mean, what kind of twit do you have to be to not understand > > > the hal files? > > > > > > > > > > using xml is just the rotten icing on that shitcake. > > There was a building up the road from here that proudly proclaimed, > Software AG The XML Company. > > Now the carpark is empty and the sign on the gate reads, Office To Let. HA! HA! HA! :)) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Friday 15 May 2009 22:51:41 Nikos Chantziaras wrote: > Alan McKinnon wrote: > > On Friday 15 May 2009 22:38:30 Nikos Chantziaras wrote: > >> pk wrote: > >>> Alan McKinnon wrote: > DeviceKit isn't even in portage yet and not many packages support it. > I don't even know if the devs will change and improve the configs > much, if at all. The problem with hal is that it's code base is a > mess, and it's design is a mish- mash of stuff throwwn together. At > least, that's what the lead hal dev says > >>> > >>> http://fedoraproject.org/wiki/Features/DeviceKit#Dependencies > >>> > >>> I haven't looked into this in any depth but it seems like Devicekit > >>> will not be an improvement (looks like it brings in the "kitchen sink" > >>> in dependencies - I'm also "allergic" to gnome)... > >> > >> I don't see how it depends on Gnome. In any case, it's not obvious to > >> me from either the link you posted nor from DeviceKit's homepage. > > > > The only useful app using DeviceKit at this point depends on gnome. > > > > So to get DeviceKit to do anything at all, you need gnome. This is due to > > current circumstance, not design. > > Then I suppose everyone else will switch to DeviceKit at some point? If > it's better than HAL then why criticize DeviceKit at all? Isn't this > what we want, getting away from HAL? I'm not sure who's criticizing DeviceKit, but it isn't me :-) Fedora seems serious about DeviceKit, and have learned from the mistakes they made with hal. I've heard rumours that F11 will ship with DeviceKit, but at this early stage very few apps use it of course. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Friday 15 May 2009 22:38:30 Nikos Chantziaras wrote: > pk wrote: > > Alan McKinnon wrote: > >> DeviceKit isn't even in portage yet and not many packages support it. I > >> don't even know if the devs will change and improve the configs much, if > >> at all. The problem with hal is that it's code base is a mess, and it's > >> design is a mish- mash of stuff throwwn together. At least, that's what > >> the lead hal dev says > > > > http://fedoraproject.org/wiki/Features/DeviceKit#Dependencies > > > > I haven't looked into this in any depth but it seems like Devicekit will > > not be an improvement (looks like it brings in the "kitchen sink" in > > dependencies - I'm also "allergic" to gnome)... > > I don't see how it depends on Gnome. In any case, it's not obvious to > me from either the link you posted nor from DeviceKit's homepage. The only useful app using DeviceKit at this point depends on gnome. So to get DeviceKit to do anything at all, you need gnome. This is due to current circumstance, not design. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Tuesday 07 April 2009 12:25:07 Volker Armin Hemmann wrote: > On Tuesday 07 April 2009, Alan McKinnon wrote: > > > > Is so OBVIOUSLY the correct way to go, and so OBVIOUSLY much easier. > > Right? I mean, what kind of twit do you have to be to not understand the > > hal files? > > > > > > using xml is just the rotten icing on that shitcake. There was a building up the road from here that proudly proclaimed, Software AG The XML Company. Now the carpark is empty and the sign on the gate reads, Office To Let. -- BigTone
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Tuesday 07 April 2009, Alan McKinnon wrote: > On Tuesday 07 April 2009 13:02:28 Nikos Chantziaras wrote: > > Volker Armin Hemmann wrote: > > > [...] > > > but my real problem is that hal crap. In their fight to make x 'easier' > > > they make it harder. keyboard layout is incorrect? well, bad luck, > > > because hal's files are a bitch to deal with. > > > > I suppose the intention was for GUI tools to do the configuration, but > > as usual in Linux (:P) no one bothered because that would mean people > > won't learn. > > > > So be happy. You're learning how HAL syntax works. That's good for > > you. No? ;-) > > > > Yes, it's wonderful. Let's face it, replacing something like > > Driver "evdev" > > with > >version="0.2"> contains="input.keys"> type="string">keyboard key="/org/freedesktop/Hal/devices/computer:system.kernel.name" > string="Linux"> type="string">evdev > > > Is so OBVIOUSLY the correct way to go, and so OBVIOUSLY much easier. Right? > I mean, what kind of twit do you have to be to not understand the hal > files? > > using xml is just the rotten icing on that shitcake.
Re: [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
On Tuesday 07 April 2009 13:02:28 Nikos Chantziaras wrote: > Volker Armin Hemmann wrote: > > [...] > > but my real problem is that hal crap. In their fight to make x 'easier' > > they make it harder. keyboard layout is incorrect? well, bad luck, > > because hal's files are a bitch to deal with. > > I suppose the intention was for GUI tools to do the configuration, but > as usual in Linux (:P) no one bothered because that would mean people > won't learn. > > So be happy. You're learning how HAL syntax works. That's good for > you. No? ;-) Yes, it's wonderful. Let's face it, replacing something like Driver "evdev" with keyboardevdev Is so OBVIOUSLY the correct way to go, and so OBVIOUSLY much easier. Right? I mean, what kind of twit do you have to be to not understand the hal files? -- alan dot mckinnon at gmail dot com
