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: - 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 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
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 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
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 Sun, May 17, 2009 at 11:00 AM, Alan McKinnon alan.mckin...@gmail.com 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
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
Mark Knecht wrote: On Sun, May 17, 2009 at 11:00 AM, Alan McKinnon alan.mckin...@gmail.com 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
On Sun, May 17, 2009 at 12:12 PM, Dale rdalek1...@gmail.com wrote: Mark Knecht wrote: On Sun, May 17, 2009 at 11:00 AM, Alan McKinnon alan.mckin...@gmail.com 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: char-major-195-* alias: pci:v10DEd*sv*sd*bc03sc02i00* alias: pci:v10DEd*sv*sd*bc03sc00i00* depends:
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 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'
was [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5 now old nvidia drivers
For you guys with older hardware/drivers, have you tried turning on CONFIG_UNUSED_SYMBOLS and recompiling the kernel to see if its helps? (Kernel hacking - Enable unused/obsolete exported symbols). I use it to support vmware server 1.x and ati flgrx drivers (with 2.6.26 or later kernels). IIRC my home machine is an IGP 440 MX running 2.6.28 (not sure of driver version off the top of my head, maybe masked to ?97?) but its working fine.
Re: was [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5 now old nvidia drivers
Adam Carter wrote: For you guys with older hardware/drivers, have you tried turning on CONFIG_UNUSED_SYMBOLS and recompiling the kernel to see if its helps? (Kernel hacking - Enable unused/obsolete exported symbols). I use it to support vmware server 1.x and ati flgrx drivers (with 2.6.26 or later kernels). IIRC my home machine is an IGP 440 MX running 2.6.28 (not sure of driver version off the top of my head, maybe masked to ?97?) but its working fine. That is a good find. I can't say that it is the problem but it was not enabled on my kernel but it is now. I'll try to test this later on as well. This sounds like what the error was reporting it couldn't find. This could work. Thanks. Dale :-) :-)
RE: was [gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5 now old nvidia drivers
For you guys with older hardware/drivers, have you tried turning on CONFIG_UNUSED_SYMBOLS and recompiling the kernel to see if its helps? (Kernel hacking - Enable unused/obsolete exported symbols). snip That is a good find. I can't say that it is the problem but it was not enabled on my kernel but it is now. I'll try to test this later on as well. This sounds like what the error was reporting it couldn't find. This could work. If it does work it would be worth a bug report to get the nvidia ebuild(s) updated similar to the ati ones; # grep -i symbol ati-drivers-8.593.ebuild if kernel_is ge 2 6 26 ! linux_chkconfig_present UNUSED_SYMBOLS; then ewarn You have to Enable unused/obsolete exported symbols in Kernel hacking section of kernel config for fglrx to load
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? /tongue_in_cheek 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
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 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: 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
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
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? /tongue_in_cheek 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
[gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
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.
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
[gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
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?
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
[gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
Volker Armin Hemmann wrote: 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? ;-) tongue_in_cheek Yes, it's wonderful. Let's face it, replacing something like Driver evdev with ?xml version=1.0 encoding=ISO-8859-1?deviceinfo version=0.2devicematch key=info.capabilities contains=input.keysmerge key=input.x11_driver type=stringkeyboard/mergematch key=/org/freedesktop/Hal/devices/computer:system.kernel.name string=Linuxmerge key=input.x11_driver type=stringevdev/merge/match/match/device/deviceinfo 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? /tongue_in_cheek using xml is just the rotten icing on that shitcake. Heh-hal worked just fine for this newbie! Thankfully, the upgrade guide owned-up to that option.
[gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
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? ;-)
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? ;-) tongue_in_cheek Yes, it's wonderful. Let's face it, replacing something like Driver evdev with ?xml version=1.0 encoding=ISO-8859-1?deviceinfo version=0.2devicematch key=info.capabilities contains=input.keysmerge key=input.x11_driver type=stringkeyboard/mergematch key=/org/freedesktop/Hal/devices/computer:system.kernel.name string=Linuxmerge key=input.x11_driver type=stringevdev/merge/match/match/device/deviceinfo 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? /tongue_in_cheek -- 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, 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? ;-) tongue_in_cheek Yes, it's wonderful. Let's face it, replacing something like Driver evdev with ?xml version=1.0 encoding=ISO-8859-1?deviceinfo version=0.2devicematch key=info.capabilities contains=input.keysmerge key=input.x11_driver type=stringkeyboard/mergematch key=/org/freedesktop/Hal/devices/computer:system.kernel.name string=Linuxmerge key=input.x11_driver type=stringevdev/merge/match/match/device/deviceinfo 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? /tongue_in_cheek using xml is just the rotten icing on that shitcake.
[gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
Volker Armin Hemmann wrote: which pretty much makes hal a bad idea. 'use hal so you don't have to edit files' and then have to edit hal's convoluted xml files instead of the simple, easy to read xorg.conf ... I don't use HAL for this at all ;) After a bit of hair-pulling, I arrived at this in my xorg.conf: Section ServerFlags Option AutoAddDevices false EndSection Section InputDevice Identifier Keyboard1 Driver kbd Option AutoRepeat 250 30 Option XkbRules xorg Option XkbModel microsoftinet EndSection Section InputDevice Identifier Mouse1 Driver evdev Option Protocol auto Option Device/dev/input/event4 Option AccelerationProfile 2 Option AdaptiveDeceleration 2 Option FilterHalflife 5 Option VelocityCoupling 0.15 Option FilterChainLength 8 EndSection Section ServerLayout # ... InputDevice Mouse1CorePointer InputDevice Keyboard1 CoreKeyboard EndSection Works just fine. Btw, the new mouse accelerator of X.Org 1.5 is awesome ;)
[gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
Joseph wrote: On 04/07/09 17:22, Volker Armin Hemmann wrote: which pretty much makes hal a bad idea. 'use hal so you don't have to edit files' and then have to edit hal's convoluted xml files instead of the simple, easy to read xorg.conf ... I'll second it, why complicate simple design; going from text file configuration to xml :-( It's optional. You can keep using xorg.conf. See my other post for an example.
[gentoo-user] Re: New xorg.conf with x11-base/xorg-server-1.5.3-r5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Volker Armin Hemmann wrote:
no, not everything. I have been switching mice on the fly with running X for
years. trackball, scroll whell mouse back to trackball back to mouse. No
extra
entry for the trackball needed - and no hal (the trackball is retired, as is
the nice, simple three-button-scroll-wheel-mouse).
That actually is a special case, as all mice share a single device,
/dev/input/mice, as well as each having their own device,
/dev/input/mouse{0,1,2,...}. In this case, the kernel itself handles
hotplugging, and X only saw /dev/input/mice.
- --
ABCD
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknbl6MACgkQOypDUo0oQOp5lwCfXP/aRwCQ9cTmv8BgazsqSBw0
4/0AoKRK611WJgzUq3H/tmoc1BqtG1pT
=a2P0
-END PGP SIGNATURE-
