Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Henrique de Moraes Holschuh h...@debian.org writes: On Sun, 26 Apr 2009, Matthew Garrett wrote: Hal checks the drive capabilities and shouldn't be polling drives that support async notifications. Is that code not working for you? It is working fine, thanks for the head's up about it disabling the poller on AN-capable devices (my laptop is not one of them, but I found one which can do that to test). Really? Please correct med if I'm wrong. I assume you are talking about the test in hald/linux/blockdev.c which sets storage.removable.support_async_notification based on the flags exported by the kernel in /sys/block/*/capability? I cannot see how this can work at the moment. There doesn't seem to be any driver setting the GENHD_FL_MEDIA_CHANGE_NOTIFY flag yet. Or am I missing something? Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Mon, 27 Apr 2009, Bjørn Mork wrote: Henrique de Moraes Holschuh h...@debian.org writes: On Sun, 26 Apr 2009, Matthew Garrett wrote: Hal checks the drive capabilities and shouldn't be polling drives that support async notifications. Is that code not working for you? It is working fine, thanks for the head's up about it disabling the poller on AN-capable devices (my laptop is not one of them, but I found one which can do that to test). Please correct med if I'm wrong. I assume you are talking about the test in hald/linux/blockdev.c which sets storage.removable.support_async_notification based on the flags exported by the kernel in /sys/block/*/capability? I cannot see how this can work at the moment. There doesn't seem to be any driver setting the GENHD_FL_MEDIA_CHANGE_NOTIFY flag yet. Or am I missing something? Hmm... I'd need to get access to that laptop to double-check, it is a co-worker's, I just asked him to boot to Linux and noticed the poller wasn't running. I assumed that was hald doing its job properly, as he said he never ran hal-disable-polling, and checked no further. If I manage to get access to that laptop again, I will do a more throughout check. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Henrique de Moraes Holschuh h...@debian.org wrote: On Tue, 21 Apr 2009, Michael Biebl wrote: powertop encourages to disable polling, so it is a big point. I agree with you in general, but I doubt polling every 2 or 16 seconds will make any significant difference power consumption wise. It does. It won't be much, but still... in any proper new laptop, that drive will have a non-broken firmware that does SATA power-saving and AN, and you are waking it up. Hal checks the drive capabilities and shouldn't be polling drives that support async notifications. Is that code not working for you? -- Matthew Garrett | mjg59-chiark.mail.debian.de...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Sun, 26 Apr 2009, Matthew Garrett wrote: Henrique de Moraes Holschuh h...@debian.org wrote: On Tue, 21 Apr 2009, Michael Biebl wrote: powertop encourages to disable polling, so it is a big point. I agree with you in general, but I doubt polling every 2 or 16 seconds will make any significant difference power consumption wise. It does. It won't be much, but still... in any proper new laptop, that drive will have a non-broken firmware that does SATA power-saving and AN, and you are waking it up. Hal checks the drive capabilities and shouldn't be polling drives that support async notifications. Is that code not working for you? It is working fine, thanks for the head's up about it disabling the poller on AN-capable devices (my laptop is not one of them, but I found one which can do that to test). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Tue, 21 Apr 2009, Michael Biebl wrote: powertop encourages to disable polling, so it is a big point. I agree with you in general, but I doubt polling every 2 or 16 seconds will make any significant difference power consumption wise. It does. It won't be much, but still... in any proper new laptop, that drive will have a non-broken firmware that does SATA power-saving and AN, and you are waking it up. Don't touch an optical drive that is quiescent. Just don't do it. Especially not on servers (where you NEVER want anything to happen without explicit permission) and laptops. Majority of users it just works, but how many of such user will use this feature? How shall I answer that? I know that I myself use auto-mounting extensively and also don't expect my father to type someting like mount /dev/hdc /mnt/cdrom You just add by default device icons for all the removable media to the desktop or to a notification area, and do the media check if the user tries to access the device in the first place (as well as the path where it would normally be mounted, such as /media/cdrom and /media/dvd), or uses the icon to mount, browse, etc. ALL non-ubber-light desktop environments support the above, and have done so for a while. So, it has never been an issue of using the CLI. If you want to enhance that support (for all I know it might have been done already), you could probably add a menu entry to those icons to automatically detect inserted media, have it default to OFF, and enable hal polling when needed, if it is changed to ON. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Matthew Garrett mgarr...@chiark.greenend.org.uk writes: powertop makes various recommendations that are only useful in very specific circumstances. Disabling polling in hal saves you a small (and probably not useful in the real world) amount of power, but is required to get to the number of wakeups per second that Arjan was aiming for. I haven't been able to measure any difference in power consumption on a typical system. I'm sure you know this, but others may not be aware of it... Modern systems have the ability to put inactive devices in a low power state to save power. See for example http://www.lesswatts.org/projects/devices-power-management/ You'll save between 0.5 and 1.5 W by enabling SATA Aggressive Link Power Management according to http://www.lesswatts.org/tips/disks.php As this definitely is measurable, I assume that your measurements have been done without enabling ALPM? Or maybe the power saving estimated by lesswatts is based on normal hard drive usage? Could you please share the details of what you've measured? Which type of drives, controllers and drivers are used in a typical system? How about a typical laptop (which in my world is the only system class where this matters anyway)? How about modern laptop (AHCI controller, SATA DVD)? Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Michael Biebl bi...@debian.org writes: See the hal-disable-polling man page. In short: hardware support for MMC media change notification is broken. Err. You are using the broken firmware argument both ways. You should follow your own advice regarding the drives spinning up: Implement a blacklist of devices with broken MMC media change notification and only poll devices in this blacklist. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Emilio Pozuelo Monfort wrote: Giacomo A. Catenazzi wrote: Emilio Pozuelo Monfort wrote: Giacomo A. Catenazzi wrote: Michael Biebl wrote: Giacomo Catenazzi wrote: For these two reason (power and security), I think Debian should offer a debconf question, (medium priority), about disabling pooling. Sorry, but this is certainly not going to happen. Why not? Is it so bad to give user a choice? No, it's bad to misuse debconf though. powertop recommend to disable hal polling. (note: powertop is not a school project) Then *maybe* it should be disabled by default, but that's not an excuse to misuse debconf IMHO. Sorry, but I don't understand the misuse. I really think it is legitimate. I don't say to have it as high priority. Why misuse? (so maybe I solve the misunderstanding. An other case: polling is useful only on desktop. The blacklist for faulty drives on the other hand, installed by default, might indeed be a good idea though. but a blacklist is only a helper, it would not have the complete list of broken hardware, and updates on stable are slow. So users need to override (easily) the decision (e.g. with the debconf question). No, users should file bugs if their HW is broken so that those can be blacklisted too. Are you joking? No For one year that user could not use debian stable? a) There are point releases. b) The user can still disable polling even without a debconf question. how? ;-) It seems that hal try harder to discourage such polling. Some low level and dangerous parameters are set in /etc/default, we can twek easily also the kernel parameters via sysctl, but hal doesn't use these nice feature. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Didier Raboud wrote: Giacomo A. Catenazzi wrote: Emilio Pozuelo Monfort wrote: No, users should file bugs if their HW is broken so that those can be blacklisted too. Are you joking? For one year that user could not use debian stable? BTW for one reported bug, there are 10 unreported bugs. I try hard to convince people to report bugs and I help translating and explaining how to report bugs. Anyway some user will no report the bug, and you can immagine the people that doesn't hit me ;-) It is also a misuse of bug reports ;-) because it is required by design. ciao cate Okay. Now reporting bugs for errors in software is a misuse… read carefully ;-) These are not errors in software. We are not correcting bugs, but are telling our users: - We know that on some hardware this feature has a bad interaction with hardware. - So we put to you (user) the burden to discovery bad hardware and telling us. We will correct it in future. BTW we try harder not to let you to disable such feature. So wait next release! so these are real bug reporting? BTW polling is not needed on correct software. It is a workaround for other (but most common) hardwares. for this reason I think waiting bug report is not a solution but only a workaround. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Gunnar Wolf wrote: Roger Leigh dijo [Wed, Apr 22, 2009 at 03:49:54PM +0100]: How shall I answer that? I know that I myself use auto-mounting extensively and also don't expect my father to type someting like mount /dev/hdc /mnt/cdrom Absolutely, but this is a separate issue. You can still, in any desktop environment, click on a CDROM icon in the filemanager/desktop/wherever, and have the CDROM automounted. That's done with pmount. This is only /automatic/ mounting on CDROM insertion, where it pops up a window or runs a program on insertion. Without this automatic HAL notification, you can still easily access the CD without any manual mount command. ...Which sadly matches user expectations. Since we deactivated the autorun facility for a laboratory of Windows machines I have nearby, users regularly knock at my door asking why their CDs don't work anymore. yes, you are right! [offtopic] On the other hand, it took few time for windows user to learn about proper ejecting of USB pen. Users can be educated more easily than developers ;-) Grandmas know how to umount and eject USB keys more easily that I had with floppy disk on early time in Linux. We know about hardware, low level disk command, but we tended to forget how good was the Linux write caching ;-) so yes, we should be able to handle such user expectation (but also maybe try to convince user to use better methods, thus that inserting USB pen and CD should be like ejecting it (with an extra user action) ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Bjørn Mork wrote: Michael Biebl bi...@debian.org writes: See the hal-disable-polling man page. In short: hardware support for MMC media change notification is broken. Err. You are using the broken firmware argument both ways. You should follow your own advice regarding the drives spinning up: Implement a blacklist of devices with broken MMC media change notification and only poll devices in this blacklist. Jocking ;-) Yes, I agree ;-) Thus we should enable polling only on broken MMC media, which doesn't support media insertion notification ;-) Who starts such blacklist? :-) ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
bj...@mork.no wrote: You'll save between 0.5 and 1.5 W by enabling SATA Aggressive Link Power Management according to http://www.lesswatts.org/tips/disks.php As this definitely is measurable, I assume that your measurements have been done without enabling ALPM? Or maybe the power saving estimated by lesswatts is based on normal hard drive usage? ALPM is only relevant for AHCI and native SATA drives. The majority of native SATA drives support asynchronous notification, so in that case there won't be any polling. Could you please share the details of what you've measured? Which type of drives, controllers and drivers are used in a typical system? How about a typical laptop (which in my world is the only system class where this matters anyway)? How about modern laptop (AHCI controller, SATA DVD)? Standard PATA optical drives, typically connected to an Intel southbridge running in piix mode. -- Matthew Garrett | mjg59-chiark.mail.debian.de...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
bj...@mork.no wrote: Michael Biebl bi...@debian.org writes: See the hal-disable-polling man page. In short: hardware support for MMC media change notification is broken. Err. You are using the broken firmware argument both ways. You should follow your own advice regarding the drives spinning up: Implement a blacklist of devices with broken MMC media change notification and only poll devices in this blacklist. The majority of drives would be in that blacklist. This is clearly not a scalable approach. I'm not aware of any PATA drives that provide notification of media change without any polling being involved. -- Matthew Garrett | mjg59-chiark.mail.debian.de...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Giacomo Catenazzi wrote: Emilio Pozuelo Monfort wrote: Giacomo A. Catenazzi wrote: Emilio Pozuelo Monfort wrote: Giacomo A. Catenazzi wrote: Michael Biebl wrote: Giacomo Catenazzi wrote: For these two reason (power and security), I think Debian should offer a debconf question, (medium priority), about disabling pooling. Sorry, but this is certainly not going to happen. Why not? Is it so bad to give user a choice? No, it's bad to misuse debconf though. powertop recommend to disable hal polling. (note: powertop is not a school project) Then *maybe* it should be disabled by default, but that's not an excuse to misuse debconf IMHO. Sorry, but I don't understand the misuse. I really think it is legitimate. I don't say to have it as high priority. Why misuse? (so maybe I solve the misunderstanding. I don't think Debconf is here to workaround bugs. This is like if we start asking questions in every package asking questions because something *could* go wrong. Either polling works fine for almost everybody, and for those who don't we blacklist the hardware, or if it doesn't work for too many people, we can whitelist those who work, or we disable polling completely if it were so broken. But let's not ask questions to disable a feature that most people won't need, specially when we can solve it by other means. An other case: polling is useful only on desktop. Why? The blacklist for faulty drives on the other hand, installed by default, might indeed be a good idea though. but a blacklist is only a helper, it would not have the complete list of broken hardware, and updates on stable are slow. So users need to override (easily) the decision (e.g. with the debconf question). No, users should file bugs if their HW is broken so that those can be blacklisted too. Are you joking? No For one year that user could not use debian stable? a) There are point releases. b) The user can still disable polling even without a debconf question. how? ;-) I dunno, but surely if you can do it through Debconf, you can do it manually. If it's not trivial, there's a manpage that could be expanded. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Michael Biebl wrote: Giacomo A. Catenazzi wrote: Michael Biebl wrote: Roger Leigh wrote: On Mon, Apr 20, 2009 at 05:52:41PM +0200, Michael Biebl wrote: Roger Leigh wrote: On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote: hal does not poll removable disks, it does though poll cd-rom drives for new media and afaik there is no way around that if you want automount for cdrom drives to work Spinning up the CD drive every 30 seconds is simply not an acceptable solution. If that's the best HAL can do, it should be disabled by default, and users will simply have to select the device by hand; we're only talking about automatic mounting here, after all. First, polling the cd drive for new media should not spin it up. If it does it is most likely a kernel/driver or firmware bug. So the bug is in a kernel driver, possibly. But, it's still hal triggering the bug by the continual polling. Second, you can very easily disable this behaviour: man hal-disable-polling Great, but it's still not the default behaviour. Does every user need to find out how to disable it after they become sufficiently annoyed by the constant spinning up of their CD drive? Why should *every* user need to find out? Seems to me as if you are exaggerating in order to make a point. For the majority of users it just works, that's why it is the default. powertop encourages to disable polling, so it is a big point. I agree with you in general, but I doubt polling every 2 or 16 seconds will make any significant difference power consumption wise. Recently it was discovered that a blinking cursor consumes a lot of power (blink is normally between 1 and 2 second interval). I think it should be the same, in this case. Take into account that both uses hardware, thus not allowing some chips to rests. I've no machine (maybe misconfiguration) with powertop indicating the power demand. Could someone do some tests? (hal-disable-polling has the option also to enable the pooling) Majority of users it just works, but how many of such user will use this feature? How shall I answer that? I know that I myself use auto-mounting extensively and also don't expect my father to type someting like mount /dev/hdc /mnt/cdrom On the other side, it was considered a bad idea for the security standpoint. [Remember also the audio CD with also some data (and maybe the famous old windoze rootkit. Which kind of CD is recognized? Could user recognize from CD which action will be done?] IMHO the right thing to do is automount, when people try to access the right directory (filemanager, open dialog windoze, ...). For these two reason (power and security), I think Debian should offer a debconf question, (medium priority), about disabling pooling. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Giacomo Catenazzi c...@debian.org wrote: Recently it was discovered that a blinking cursor consumes a lot of power (blink is normally between 1 and 2 second interval). I think it should be the same, in this case. Take into account that both uses hardware, thus not allowing some chips to rests. No, they're not comparable. The difference in power draw between active and idle in modern GPUs can be on the order of 10-20W. That's not the case for ATA hardware, and even if it were we don't do anything to idle the chipsets at the moment. -- Matthew Garrett | mjg59-chiark.mail.debian.de...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Steve Langasek vor...@debian.org wrote: On Tue, Apr 21, 2009 at 06:13:47PM +0200, Michael Biebl wrote: powertop encourages to disable polling, so it is a big point. I agree with you in general, but I doubt polling every 2 or 16 seconds will make any significant difference power consumption wise. If it requires the drive to be spun up (due to limitations in the firmware), it most certainly does. This is (by far) the uncommon case. Blacklisting drives where this does happen seems reasonable. -- Matthew Garrett | mjg59-chiark.mail.debian.de...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Giacomo Catenazzi wrote: Michael Biebl wrote: Giacomo A. Catenazzi wrote: Michael Biebl wrote: Roger Leigh wrote: On Mon, Apr 20, 2009 at 05:52:41PM +0200, Michael Biebl wrote: Roger Leigh wrote: On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote: hal does not poll removable disks, it does though poll cd-rom drives for new media and afaik there is no way around that if you want automount for cdrom drives to work Spinning up the CD drive every 30 seconds is simply not an acceptable solution. If that's the best HAL can do, it should be disabled by default, and users will simply have to select the device by hand; we're only talking about automatic mounting here, after all. First, polling the cd drive for new media should not spin it up. If it does it is most likely a kernel/driver or firmware bug. So the bug is in a kernel driver, possibly. But, it's still hal triggering the bug by the continual polling. Second, you can very easily disable this behaviour: man hal-disable-polling Great, but it's still not the default behaviour. Does every user need to find out how to disable it after they become sufficiently annoyed by the constant spinning up of their CD drive? Why should *every* user need to find out? Seems to me as if you are exaggerating in order to make a point. For the majority of users it just works, that's why it is the default. powertop encourages to disable polling, so it is a big point. I agree with you in general, but I doubt polling every 2 or 16 seconds will make any significant difference power consumption wise. Recently it was discovered that a blinking cursor consumes a lot of power (blink is normally between 1 and 2 second interval). I think it should be the same, in this case. Take into account that both uses hardware, thus not allowing some chips to rests. I've no machine (maybe misconfiguration) with powertop indicating the power demand. Could someone do some tests? (hal-disable-polling has the option also to enable the pooling) It makes no measurable difference here on my laptop (nx7000) running Debian Lenny. Majority of users it just works, but how many of such user will use this feature? How shall I answer that? I know that I myself use auto-mounting extensively and also don't expect my father to type someting like mount /dev/hdc /mnt/cdrom On the other side, it was considered a bad idea for the security standpoint. [Remember also the audio CD with also some data (and maybe the famous old windoze rootkit. Which kind of CD is recognized? Could user recognize from CD which action will be done?] I think what you are referring too, is the so-called autorun feature of windows. I need to clarify here, that hal itself does *not* do the automounting itself. It merely provides the information when a media is inserted or not. The desktop environment (or tools like volman) listen to those events and trigger the actual mounting. This way, you can very easily configure within the desktop environment, which kind of policy/actions you want have (see e.g. gnome-volume-manager). Also, afaik none of the big desktop environments starts any scripts on a removable media without asking you first. IMHO the right thing to do is automount, when people try to access the right directory (filemanager, open dialog windoze, ...). Correct, that's up to the user to decide. But for that to work correctly, the need the information provided by hal. Just wanted to clarify that, as there seem to be some misconceptions about hal even if it has become completely OT. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Giacomo Catenazzi wrote: For these two reason (power and security), I think Debian should offer a debconf question, (medium priority), about disabling pooling. Sorry, but this is certainly not going to happen. The blacklist for faulty drives on the other hand, installed by default, might indeed be a good idea though. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Tue, Apr 21, 2009 at 06:13:47PM +0200, Michael Biebl wrote: Giacomo A. Catenazzi wrote: Michael Biebl wrote: powertop encourages to disable polling, so it is a big point. I agree with you in general, but I doubt polling every 2 or 16 seconds will make any significant difference power consumption wise. Majority of users it just works, but how many of such user will use this feature? How shall I answer that? I know that I myself use auto-mounting extensively and also don't expect my father to type someting like mount /dev/hdc /mnt/cdrom Absolutely, but this is a separate issue. You can still, in any desktop environment, click on a CDROM icon in the filemanager/desktop/wherever, and have the CDROM automounted. That's done with pmount. This is only /automatic/ mounting on CDROM insertion, where it pops up a window or runs a program on insertion. Without this automatic HAL notification, you can still easily access the CD without any manual mount command. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Giacomo A. Catenazzi wrote: Michael Biebl wrote: Giacomo Catenazzi wrote: For these two reason (power and security), I think Debian should offer a debconf question, (medium priority), about disabling pooling. Sorry, but this is certainly not going to happen. Why not? Is it so bad to give user a choice? No, it's bad to misuse debconf though. The blacklist for faulty drives on the other hand, installed by default, might indeed be a good idea though. but a blacklist is only a helper, it would not have the complete list of broken hardware, and updates on stable are slow. So users need to override (easily) the decision (e.g. with the debconf question). No, users should file bugs if their HW is broken so that those can be blacklisted too. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Michael Biebl wrote: Giacomo Catenazzi wrote: Michael Biebl wrote: Giacomo A. Catenazzi wrote: Michael Biebl wrote: Roger Leigh wrote: On Mon, Apr 20, 2009 at 05:52:41PM +0200, Michael Biebl wrote: Roger Leigh wrote: On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote: hal does not poll removable disks, it does though poll cd-rom drives for new media and afaik there is no way around that if you want automount for cdrom drives to work Spinning up the CD drive every 30 seconds is simply not an acceptable solution. If that's the best HAL can do, it should be disabled by default, and users will simply have to select the device by hand; we're only talking about automatic mounting here, after all. First, polling the cd drive for new media should not spin it up. If it does it is most likely a kernel/driver or firmware bug. So the bug is in a kernel driver, possibly. But, it's still hal triggering the bug by the continual polling. Second, you can very easily disable this behaviour: man hal-disable-polling Great, but it's still not the default behaviour. Does every user need to find out how to disable it after they become sufficiently annoyed by the constant spinning up of their CD drive? Why should *every* user need to find out? Seems to me as if you are exaggerating in order to make a point. For the majority of users it just works, that's why it is the default. powertop encourages to disable polling, so it is a big point. I agree with you in general, but I doubt polling every 2 or 16 seconds will make any significant difference power consumption wise. Recently it was discovered that a blinking cursor consumes a lot of power (blink is normally between 1 and 2 second interval). I think it should be the same, in this case. Take into account that both uses hardware, thus not allowing some chips to rests. I've no machine (maybe misconfiguration) with powertop indicating the power demand. Could someone do some tests? (hal-disable-polling has the option also to enable the pooling) It makes no measurable difference here on my laptop (nx7000) running Debian Lenny. ok, this confirm also Matthew Garrett analysis, and it is good. But so why powertop reccomend to disable pooling? Majority of users it just works, but how many of such user will use this feature? How shall I answer that? I know that I myself use auto-mounting extensively and also don't expect my father to type someting like mount /dev/hdc /mnt/cdrom On the other side, it was considered a bad idea for the security standpoint. [Remember also the audio CD with also some data (and maybe the famous old windoze rootkit. Which kind of CD is recognized? Could user recognize from CD which action will be done?] I think what you are referring too, is the so-called autorun feature of windows. I need to clarify here, that hal itself does *not* do the automounting itself. It merely provides the information when a media is inserted or not. The desktop environment (or tools like volman) listen to those events and trigger the actual mounting. (...) IMHO the right thing to do is automount, when people try to access the right directory (filemanager, open dialog windoze, ...). Correct, that's up to the user to decide. But for that to work correctly, the need the information provided by hal. Just wanted to clarify that, as there seem to be some misconceptions about hal even if it has become completely OT. Yes, I was confused, but also you. The real automounting is done by kernel, when accessing to a directory. Old method, no need for HAL (for automounting, I'm not speaking of other features of HAL). So polling could be done when user try to access /media/cdrom, not when screensaver is running. This way, you can very easily configure within the desktop environment, which kind of policy/actions you want have (see e.g. gnome-volume-manager). Also, afaik none of the big desktop environments starts any scripts on a removable media without asking you first. No, but I hate KDE opening windows when I insert a pen o a cdrom. (feature which I disable as fast as possible). I really hate when system *try* to be smarter that me, a stupid user, and they force me to do something I don't like to do (and usually they fails anyway). It is not the real design of HAL, but it seems that actual use of HAL goes in this wrong direction. is seems, but maybe I'm wrong. Automatism is good when done right, but if you smell some guess, the automatism is *wrong*. I don't care if 90% of time the guesses are correct, it will be a nightmare to the minority of user. [see broken hardware not in blacklist, in a non-expert user machine] HAL could not solve all hardware problem, so don't try to solve all hardware problem with HALL. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Emilio Pozuelo Monfort wrote: Giacomo A. Catenazzi wrote: Michael Biebl wrote: Giacomo Catenazzi wrote: For these two reason (power and security), I think Debian should offer a debconf question, (medium priority), about disabling pooling. Sorry, but this is certainly not going to happen. Why not? Is it so bad to give user a choice? No, it's bad to misuse debconf though. powertop recommend to disable hal polling. (note: powertop is not a school project) The blacklist for faulty drives on the other hand, installed by default, might indeed be a good idea though. but a blacklist is only a helper, it would not have the complete list of broken hardware, and updates on stable are slow. So users need to override (easily) the decision (e.g. with the debconf question). No, users should file bugs if their HW is broken so that those can be blacklisted too. Are you joking? For one year that user could not use debian stable? BTW for one reported bug, there are 10 unreported bugs. I try hard to convince people to report bugs and I help translating and explaining how to report bugs. Anyway some user will no report the bug, and you can immagine the people that doesn't hit me ;-) It is also a misuse of bug reports ;-) because it is required by design. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Michael Biebl wrote: Giacomo Catenazzi wrote: For these two reason (power and security), I think Debian should offer a debconf question, (medium priority), about disabling pooling. Sorry, but this is certainly not going to happen. Why not? Is it so bad to give user a choice? The blacklist for faulty drives on the other hand, installed by default, might indeed be a good idea though. but a blacklist is only a helper, it would not have the complete list of broken hardware, and updates on stable are slow. So users need to override (easily) the decision (e.g. with the debconf question). ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Giacomo A. Catenazzi wrote: Emilio Pozuelo Monfort wrote: No, users should file bugs if their HW is broken so that those can be blacklisted too. Are you joking? For one year that user could not use debian stable? BTW for one reported bug, there are 10 unreported bugs. I try hard to convince people to report bugs and I help translating and explaining how to report bugs. Anyway some user will no report the bug, and you can immagine the people that doesn't hit me ;-) It is also a misuse of bug reports ;-) because it is required by design. ciao cate Okay. Now reporting bugs for errors in software is a misuse… Explain me… -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Roger Leigh dijo [Wed, Apr 22, 2009 at 03:49:54PM +0100]: How shall I answer that? I know that I myself use auto-mounting extensively and also don't expect my father to type someting like mount /dev/hdc /mnt/cdrom Absolutely, but this is a separate issue. You can still, in any desktop environment, click on a CDROM icon in the filemanager/desktop/wherever, and have the CDROM automounted. That's done with pmount. This is only /automatic/ mounting on CDROM insertion, where it pops up a window or runs a program on insertion. Without this automatic HAL notification, you can still easily access the CD without any manual mount command. ...Which sadly matches user expectations. Since we deactivated the autorun facility for a laboratory of Windows machines I have nearby, users regularly knock at my door asking why their CDs don't work anymore. Grmbl... -- Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Giacomo A. Catenazzi wrote: Emilio Pozuelo Monfort wrote: Giacomo A. Catenazzi wrote: Michael Biebl wrote: Giacomo Catenazzi wrote: For these two reason (power and security), I think Debian should offer a debconf question, (medium priority), about disabling pooling. Sorry, but this is certainly not going to happen. Why not? Is it so bad to give user a choice? No, it's bad to misuse debconf though. powertop recommend to disable hal polling. (note: powertop is not a school project) Then *maybe* it should be disabled by default, but that's not an excuse to misuse debconf IMHO. The blacklist for faulty drives on the other hand, installed by default, might indeed be a good idea though. but a blacklist is only a helper, it would not have the complete list of broken hardware, and updates on stable are slow. So users need to override (easily) the decision (e.g. with the debconf question). No, users should file bugs if their HW is broken so that those can be blacklisted too. Are you joking? No For one year that user could not use debian stable? a) There are point releases. b) The user can still disable polling even without a debconf question. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Giacomo A. Catenazzi wrote: Emilio Pozuelo Monfort wrote: No, users should file bugs if their HW is broken so that those can be blacklisted too. Are you joking? For one year that user could not use debian stable? This says far more about the disadvantages to our stable release policy than it does about hal or any other specific piece of software in the release. - David Nusinow -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Giacomo A. Catenazzi c...@debian.org wrote: Michael Biebl wrote: It makes no measurable difference here on my laptop (nx7000) running Debian Lenny. ok, this confirm also Matthew Garrett analysis, and it is good. But so why powertop reccomend to disable pooling? powertop makes various recommendations that are only useful in very specific circumstances. Disabling polling in hal saves you a small (and probably not useful in the real world) amount of power, but is required to get to the number of wakeups per second that Arjan was aiming for. I haven't been able to measure any difference in power consumption on a typical system. -- Matthew Garrett | mjg59-chiark.mail.debian.de...@srcf.ucam.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Le mercredi 22 avril 2009 à 14:50 -0400, David Nusinow a écrit : This says far more about the disadvantages to our stable release policy than it does about hal or any other specific piece of software in the release. And actually this is simply untrue. I’ve seen similar fixes accepted in point releases, and I haven’t seen the SRMs say they would setup stricter rules for lenny. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Josselin Mouette j...@debian.org writes: If it’s just your decision, why are you bitching on this list? That's a good question. It was fun for a while. But I think the spectators are getting a bit bored. I'll stop now. Thanks for your answers. Believe it or not, but I've learned a lot about hal from this discussion. I might even find it useful in the end :-) Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Michael Biebl wrote: Roger Leigh wrote: On Mon, Apr 20, 2009 at 05:52:41PM +0200, Michael Biebl wrote: Roger Leigh wrote: On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote: hal does not poll removable disks, it does though poll cd-rom drives for new media and afaik there is no way around that if you want automount for cdrom drives to work Spinning up the CD drive every 30 seconds is simply not an acceptable solution. If that's the best HAL can do, it should be disabled by default, and users will simply have to select the device by hand; we're only talking about automatic mounting here, after all. First, polling the cd drive for new media should not spin it up. If it does it is most likely a kernel/driver or firmware bug. So the bug is in a kernel driver, possibly. But, it's still hal triggering the bug by the continual polling. Second, you can very easily disable this behaviour: man hal-disable-polling Great, but it's still not the default behaviour. Does every user need to find out how to disable it after they become sufficiently annoyed by the constant spinning up of their CD drive? Why should *every* user need to find out? Seems to me as if you are exaggerating in order to make a point. For the majority of users it just works, that's why it is the default. powertop encourages to disable polling, so it is a big point. Majority of users it just works, but how many of such user will use this feature? Is it really needed? 10-15 year ago hardware and kernel started to support new media detection on floppy disk (and IIRC on CD), so real hardware and kernel should support this sort of hotplug, without polling, or I miss completely the issue? ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Giacomo A. Catenazzi wrote: Michael Biebl wrote: Roger Leigh wrote: On Mon, Apr 20, 2009 at 05:52:41PM +0200, Michael Biebl wrote: Roger Leigh wrote: On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote: hal does not poll removable disks, it does though poll cd-rom drives for new media and afaik there is no way around that if you want automount for cdrom drives to work Spinning up the CD drive every 30 seconds is simply not an acceptable solution. If that's the best HAL can do, it should be disabled by default, and users will simply have to select the device by hand; we're only talking about automatic mounting here, after all. First, polling the cd drive for new media should not spin it up. If it does it is most likely a kernel/driver or firmware bug. So the bug is in a kernel driver, possibly. But, it's still hal triggering the bug by the continual polling. Second, you can very easily disable this behaviour: man hal-disable-polling Great, but it's still not the default behaviour. Does every user need to find out how to disable it after they become sufficiently annoyed by the constant spinning up of their CD drive? Why should *every* user need to find out? Seems to me as if you are exaggerating in order to make a point. For the majority of users it just works, that's why it is the default. powertop encourages to disable polling, so it is a big point. I agree with you in general, but I doubt polling every 2 or 16 seconds will make any significant difference power consumption wise. Majority of users it just works, but how many of such user will use this feature? How shall I answer that? I know that I myself use auto-mounting extensively and also don't expect my father to type someting like mount /dev/hdc /mnt/cdrom Is it really needed? 10-15 year ago hardware and kernel started to support new media detection on floppy disk (and IIRC on CD), so real hardware and kernel should support this sort of hotplug, without polling, or I miss completely the issue? See the hal-disable-polling man page. In short: hardware support for MMC media change notification is broken. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Tue, Apr 21, 2009 at 06:13:47PM +0200, Michael Biebl wrote: powertop encourages to disable polling, so it is a big point. I agree with you in general, but I doubt polling every 2 or 16 seconds will make any significant difference power consumption wise. If it requires the drive to be spun up (due to limitations in the firmware), it most certainly does. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Josselin Mouette j...@debian.org writes: Le jeudi 16 avril 2009 à 15:06 +0200, Bjørn Mork a écrit : a) laptop keys remapped or disappearing (might be caused by the driver - I don't know) Yes, they are remapped to the standard XF86* names, so that applications configuring shortcuts can have sensible defaults. So you justify breaking existing setups by claiming the new configuration is more sensible. How many times? How often? If you know how to homogenize keycodes between different keyboard models without actually changing the keycodes, good for you, but I don’t. Also, do you prefer configuring a keycode named “0xae” or “XF86AudioLowerVolume”? I prefer non-broken defaults. hal defaults are broken. No, the keys are not always mapped to standard XF86* names. They are sometimes mapped into the blue. See e.g. bug #504643, which explains my disappearing keys. Finding it took some time, since stupid me thought regrep KEY_RADIO /usr/share/hal. would reveal any hal related problems. This bug will bite every ThinkPad-user when /proc/acpi/event is removed and we are forced to replace acpid functionality (already so in the latest squeeze kernels). And the cause is a simple case of a broken default key remapping, reported more than 5 months ago. Open through several new releases of hal-info. You don't seriously beleive that I'm going to trust hal while it's in a state like this, do you? b) unwanted auto-mounting HAL will not do auto-mounting by itself. Some user-level daemon must be listening for events and requesting the actual mount. The auto-mount support in hal is unwanted even without such daemons. Continously polling all removable storage is a very bad default IMHO. And why do it if there's no daemon listening for the events anyway? You’re mixing apples and oranges. I'm sure you're right. You see, there is no documentation for the oranges, which may have made me assume they are fruit just like the apples. The hal default polling removable disks is annoying, useless, and an example of bad hal design. You may of course continue to ignore this by claiming that I don't know what I'm talking about. Unfortunately, it won't do much more that continue to document hal as a dead-end with a big STAY AWAY! warning sign. You might as well implement a popup asking the user if (s)he is present every 30 seconds. I'm sure it would be very useful for hal to know, and it woulb be only slightly more annoying than the disk polling. Yes, I do know that the most annoying features can be disabled. My concerns are the bad Debian default values, not the features themselves, combined with forcing these packages on the user. There's absolutely no excuse for forcing every X user to accept all the bogus key remapping in hal-info. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Bjørn Mork wrote: [lot of fud deleted] The hal default polling removable disks is annoying, useless, and an example of bad hal design. You may of course continue to ignore this by claiming that I don't know what I'm talking about. Unfortunately, it Seems you are confusing a lot of things, polling removable disks being one. hal does not poll removable disks, it does though poll cd-rom drives for new media and afaik there is no way around that if you want automount for cdrom drives to work (newer sata driver *should* support hardware notifications when using libata [1]). Cheers, Michael [1] http://kerneltrap.org/Linux/Asynchronous_Event_Notification_Infrastructure -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Julien Cristau wrote: hal breaks existing working configurations without warnings. The simple test case is using a non-US keyboard properly configured as such in xorg.conf. Introduce evdev/hal and watch users get frustrated. The problem of course: keyboard layout cannot be auto-configured. But why ignore existing configuration? we don't ignore existing keymap configuration, and you get the same layout after the upgrade as was configured in xorg.conf. I a) got an english keyboard instead of a german one b) sudently lost my ~, | etc. with the upgrade. I would not call that preserving the configuration, honestly. Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Mon, Apr 20, 2009 at 16:24:59 +0200, Rene Engelhard wrote: Julien Cristau wrote: hal breaks existing working configurations without warnings. The simple test case is using a non-US keyboard properly configured as such in xorg.conf. Introduce evdev/hal and watch users get frustrated. The problem of course: keyboard layout cannot be auto-configured. But why ignore existing configuration? we don't ignore existing keymap configuration, and you get the same layout after the upgrade as was configured in xorg.conf. I a) got an english keyboard instead of a german one b) sudently lost my ~, | etc. with the upgrade. I would not call that preserving the configuration, honestly. I would call it a bug. If people tell us about them, some bugs get fixed. If not, well... Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote: Bjørn Mork wrote: [lot of fud deleted] The hal default polling removable disks is annoying, useless, and an example of bad hal design. You may of course continue to ignore this by claiming that I don't know what I'm talking about. Unfortunately, it Seems you are confusing a lot of things, polling removable disks being one. hal does not poll removable disks, it does though poll cd-rom drives for new media and afaik there is no way around that if you want automount for cdrom drives to work Spinning up the CD drive every 30 seconds is simply not an acceptable solution. If that's the best HAL can do, it should be disabled by default, and users will simply have to select the device by hand; we're only talking about automatic mounting here, after all. It's the primary reason I try to remove HAL whenever possible. #370186 might have been closed, but it's still present on all my hardware, and it's still IMO a grave bug. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Roger Leigh wrote: On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote: hal does not poll removable disks, it does though poll cd-rom drives for new media and afaik there is no way around that if you want automount for cdrom drives to work Spinning up the CD drive every 30 seconds is simply not an acceptable solution. If that's the best HAL can do, it should be disabled by default, and users will simply have to select the device by hand; we're only talking about automatic mounting here, after all. First, polling the cd drive for new media should not spin it up. If it does it is most likely a kernel/driver or firmware bug. Second, you can very easily disable this behaviour: man hal-disable-polling Anyways, this has become very OT. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Mon, Apr 20, 2009 at 05:52:41PM +0200, Michael Biebl wrote: Roger Leigh wrote: On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote: hal does not poll removable disks, it does though poll cd-rom drives for new media and afaik there is no way around that if you want automount for cdrom drives to work Spinning up the CD drive every 30 seconds is simply not an acceptable solution. If that's the best HAL can do, it should be disabled by default, and users will simply have to select the device by hand; we're only talking about automatic mounting here, after all. First, polling the cd drive for new media should not spin it up. If it does it is most likely a kernel/driver or firmware bug. So the bug is in a kernel driver, possibly. But, it's still hal triggering the bug by the continual polling. Second, you can very easily disable this behaviour: man hal-disable-polling Great, but it's still not the default behaviour. Does every user need to find out how to disable it after they become sufficiently annoyed by the constant spinning up of their CD drive? Seriously, mine all spin up just a second after they spin down from the previous poll until I kill HAL (-addon-storage). This continual wear and tear on the drive is unreasonable. I don't want HAL to kill my hardware and constantly annoy me, just because I leave a CD in the drive. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Roger Leigh wrote: On Mon, Apr 20, 2009 at 05:52:41PM +0200, Michael Biebl wrote: Roger Leigh wrote: On Mon, Apr 20, 2009 at 03:55:15PM +0200, Michael Biebl wrote: hal does not poll removable disks, it does though poll cd-rom drives for new media and afaik there is no way around that if you want automount for cdrom drives to work Spinning up the CD drive every 30 seconds is simply not an acceptable solution. If that's the best HAL can do, it should be disabled by default, and users will simply have to select the device by hand; we're only talking about automatic mounting here, after all. First, polling the cd drive for new media should not spin it up. If it does it is most likely a kernel/driver or firmware bug. So the bug is in a kernel driver, possibly. But, it's still hal triggering the bug by the continual polling. Second, you can very easily disable this behaviour: man hal-disable-polling Great, but it's still not the default behaviour. Does every user need to find out how to disable it after they become sufficiently annoyed by the constant spinning up of their CD drive? Why should *every* user need to find out? Seems to me as if you are exaggerating in order to make a point. For the majority of users it just works, that's why it is the default. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Le lundi 20 avril 2009 à 18:26 +0200, Michael Biebl a écrit : Second, you can very easily disable this behaviour: man hal-disable-polling Great, but it's still not the default behaviour. Does every user need to find out how to disable it after they become sufficiently annoyed by the constant spinning up of their CD drive? Why should *every* user need to find out? Seems to me as if you are exaggerating in order to make a point. For the majority of users it just works, that's why it is the default. Why not introduce a FDI that disables polling for drives that are known to be broken? -- .''`. Debian 5.0 “Lenny” has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he’d melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Twas brillig at 19:36:30 20.04.2009 UTC+02 when j...@debian.org did gyre and gimble: Why should *every* user need to find out? Seems to me as if you are exaggerating in order to make a point. For the majority of users it just works, that's why it is the default. JM Why not introduce a FDI that disables polling for drives that are JM known to be broken? Most of ATAPI CDROMs are, so it makes HAL media detection quite useless :) -- pgpF6DMmWqzc5.pgp Description: PGP signature
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Le lundi 20 avril 2009 à 10:26 +0200, Bjørn Mork a écrit : I prefer non-broken defaults. hal defaults are broken. No, the keys are not always mapped to standard XF86* names. They are sometimes mapped into the blue. See e.g. bug #504643, which explains my disappearing keys. Finding it took some time, since stupid me thought regrep KEY_RADIO /usr/share/hal. would reveal any hal related problems. So, the HAL defaults are broken *for one keyboard model*. Geez, without HAL your function keys wouldn’t actually work at all for many models without jumping through incredible hoops or installing specific software. I can’t believe you think this should be encouraged. There are bugs? Fine, let’s fix them. You don't seriously beleive that I'm going to trust hal while it's in a state like this, do you? So you found one bug in HAL, and you deem it unsuitable for everyone? -- .''`. Debian 5.0 “Lenny” has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he’d melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Josselin Mouette wrote: Le lundi 20 avril 2009 à 18:26 +0200, Michael Biebl a écrit : Second, you can very easily disable this behaviour: man hal-disable-polling Great, but it's still not the default behaviour. Does every user need to find out how to disable it after they become sufficiently annoyed by the constant spinning up of their CD drive? Why should *every* user need to find out? Seems to me as if you are exaggerating in order to make a point. For the majority of users it just works, that's why it is the default. Why not introduce a FDI that disables polling for drives that are known to be broken? You mean like /usr/share/doc/hal/examples/no-cd-media-check.fdi and the note in README.Debian? My feeling is, that whatever we do, some people will still complain. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Le lundi 20 avril 2009 à 19:43 +0200, Michael Biebl a écrit : Josselin Mouette wrote: Why not introduce a FDI that disables polling for drives that are known to be broken? You mean like /usr/share/doc/hal/examples/no-cd-media-check.fdi and the note in README.Debian? Something like this, but installed by default with an up-to-date list. My feeling is, that whatever we do, some people will still complain. But if we do things right, we can reasonably say that those who complain are assholes. Currently, they still have a point. -- .''`. Debian 5.0 “Lenny” has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he’d melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Le mardi 21 avril 2009 à 00:38 +0700, Mikhail Gusarov a écrit : Twas brillig at 19:36:30 20.04.2009 UTC+02 when j...@debian.org did gyre and gimble: JM Why not introduce a FDI that disables polling for drives that are JM known to be broken? Most of ATAPI CDROMs are, so it makes HAL media detection quite useless :) I own several different ATA drives, and I’ve never seen this behavior. -- .''`. Debian 5.0 “Lenny” has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he’d melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Josselin Mouette j...@debian.org writes: Le lundi 20 avril 2009 à 10:26 +0200, Bjørn Mork a écrit : I prefer non-broken defaults. hal defaults are broken. No, the keys are not always mapped to standard XF86* names. They are sometimes mapped into the blue. See e.g. bug #504643, which explains my disappearing keys. Finding it took some time, since stupid me thought regrep KEY_RADIO /usr/share/hal. would reveal any hal related problems. So, the HAL defaults are broken *for one keyboard model*. Make that for every keyboard I'm using. Why would the number of working keyboards matter? If you care about such statistics you should probably use Windows. It works for far more people than Debian does. Geez, without HAL your function keys wouldn’t actually work at all Well, it did work with acpid as long as the kernel supported /proc/acpi/event. No need for hal at all those days. for many models without jumping through incredible hoops or installing specific software. I can’t believe you think this should be encouraged. You still need the specific software to actually do something useful in response to these keys. It's not like they are supposed to generate some character in your terminal. They are supposed to trigger some action, like e.g. switching video outputs or enabling bluetooth. AFAIK, you won't get around the specific software requirement. There are bugs? Fine, let’s fix them. Doesn't look like anybody really does that. 5 months and 4 releases without fixing a trivial bug like this? Looks non-maintained to me. You don't seriously beleive that I'm going to trust hal while it's in a state like this, do you? So you found one bug in HAL, and you deem it unsuitable for everyone? No, I don't. You really could need a copy of Reading for Dummies. *I'm* not going to trust hal. Everyone else should make their own decision. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Le lundi 20 avril 2009 à 22:13 +0200, Bjørn Mork a écrit : So, the HAL defaults are broken *for one keyboard model*. Make that for every keyboard I'm using. Why would the number of working keyboards matter? If you care about such statistics you should probably use Windows. It works for far more people than Debian does. Bullshit. Windows doesn’t support any single model of multimedia keyboard out of the box. You need specific drivers for each of them. Geez, without HAL your function keys wouldn’t actually work at all Well, it did work with acpid as long as the kernel supported /proc/acpi/event. No need for hal at all those days. It did because you were one of the lucky ones owning a model for which these keys directly sent ACPI events. With HAL, this works for a much larger number of models. for many models without jumping through incredible hoops or installing specific software. I can’t believe you think this should be encouraged. You still need the specific software to actually do something useful in response to these keys. It's not like they are supposed to generate some character in your terminal. They are supposed to trigger some action, like e.g. switching video outputs or enabling bluetooth. AFAIK, you won't get around the specific software requirement. Yes you will. When a key triggers stopping the wifi signal, it needs the same action whether your laptop is a Sonovo or a Toshidell. The same holds for most if not all the multimedia keys. Using the same abstraction layer for all of them allows to put the same software behind all of them to accomplish the same task. *I'm* not going to trust hal. Everyone else should make their own decision. If it’s just your decision, why are you bitching on this list? -- .''`. Debian 5.0 “Lenny” has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he’d melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Mon, Apr 20 2009, Josselin Mouette wrote: Le lundi 20 avril 2009 à 10:26 +0200, Bjørn Mork a écrit : I prefer non-broken defaults. hal defaults are broken. No, the keys are not always mapped to standard XF86* names. They are sometimes mapped into the blue. See e.g. bug #504643, which explains my disappearing keys. Finding it took some time, since stupid me thought regrep KEY_RADIO /usr/share/hal. would reveal any hal related problems. So, the HAL defaults are broken *for one keyboard model*. Geez, without HAL your function keys wouldn’t actually work at all for many models without jumping through incredible hoops or installing specific software. I can’t believe you think this should be encouraged. Well, not just one keyboard model, to be fait. I lost my arrow keys, and the right alt, meta, and right control, home/end page up/down, and some keypad keys all got scrambled. There are bugs? Fine, let’s fix them. I'll be happy to help. manoj -- He has shown you, o man, what is good. And what does the Lord ask of you, but to do justice, and to love kindness, and to walk humbly before your God? Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Wed, Apr 15, 2009 at 10:25:36AM +0200, Bjørn Mork wrote: I still haven't got a clue how to really fix this, but have resorted to this for now: ?xml version=1.0 encoding=UTF-8? deviceinfo version=0.2 device match key=info.capabilities contains=input.keyboard merge key=input.xkb.model type=stringpc105/merge merge key=input.xkb.layout type=stringno/merge /match /device /deviceinfo ...except with latest hal/X.org/whatever it also stopped working. Latest X.org pulled in console-setup, and now the settings under /etc/hal/fdi/policy get ignored. What a mess. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Le jeudi 16 avril 2009 à 00:34 +0200, Bjørn Mork a écrit : My list of hal related regressions are a) laptop keys remapped or disappearing (might be caused by the driver - I don't know) Yes, they are remapped to the standard XF86* names, so that applications configuring shortcuts can have sensible defaults. b) unwanted auto-mounting HAL will not do auto-mounting by itself. Some user-level daemon must be listening for events and requesting the actual mount. -- .''`. Debian 5.0 “Lenny” has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he’d melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Josselin Mouette j...@debian.org writes: Le jeudi 16 avril 2009 à 00:34 +0200, Bjørn Mork a écrit : My list of hal related regressions are a) laptop keys remapped or disappearing (might be caused by the driver - I don't know) Yes, they are remapped to the standard XF86* names, so that applications configuring shortcuts can have sensible defaults. So you justify breaking existing setups by claiming the new configuration is more sensible. How many times? How often? Every breakage is still a regression in my eyes. b) unwanted auto-mounting HAL will not do auto-mounting by itself. Some user-level daemon must be listening for events and requesting the actual mount. The auto-mount support in hal is unwanted even without such daemons. Continously polling all removable storage is a very bad default IMHO. And why do it if there's no daemon listening for the events anyway? Yes, I know it can be disabled. Having to disable such things to avoid power consumption, noise and wear regressions is still annoying. An the design sucks. Daemons wanting events from a polling source should register with the poller, and polling should be disabled by default until such a daemon registered itself. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Le jeudi 16 avril 2009 à 15:06 +0200, Bjørn Mork a écrit : a) laptop keys remapped or disappearing (might be caused by the driver - I don't know) Yes, they are remapped to the standard XF86* names, so that applications configuring shortcuts can have sensible defaults. So you justify breaking existing setups by claiming the new configuration is more sensible. How many times? How often? If you know how to homogenize keycodes between different keyboard models without actually changing the keycodes, good for you, but I don’t. Also, do you prefer configuring a keycode named “0xae” or “XF86AudioLowerVolume”? b) unwanted auto-mounting HAL will not do auto-mounting by itself. Some user-level daemon must be listening for events and requesting the actual mount. The auto-mount support in hal is unwanted even without such daemons. Continously polling all removable storage is a very bad default IMHO. And why do it if there's no daemon listening for the events anyway? You’re mixing apples and oranges. -- .''`. Debian 5.0 “Lenny” has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he’d melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Thu, 2009-04-16 at 10:18 +0200, Gabor Gombas wrote: ...except with latest hal/X.org/whatever it also stopped working. Latest X.org pulled in console-setup, and now the settings under /etc/hal/fdi/policy get ignored. What a mess. that's called a bug. ranting on mailing lists doesn't do anything to fix it. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Julien Cristau jcris...@debian.org writes: On Sun, 2009-04-12 at 14:04 +0200, Michael Meskes wrote: On Mon, Apr 06, 2009 at 09:55:39PM +0200, Michael Biebl wrote: As (co-)maintainer of pm-utils and hal, I'd prefer if we could work towards standardizing on one power management stack in Debian (and not install 3 by default [1]), i.e. I'd support in phasing out acpi-support and would gladly accept patches for hal and pm-utils which add (if there are) any missing bits from acpi-support. Not sure whether most users agree after reading #515214. 515214 isn't most users. most users just want things to work. False. All users want all things to work. The just is nice to have, but not important. It's infinitely better to have to configure things than not being able to. But I think you're on to the problem: It's true that hal makes most things work. The rest can't be made to work if you use hal. Or at least require you to configure a new, non-intuitive, complex system. #515214 is about the rest, the way I read it. Well, you can always argue that the rest can be fixed. Provide patches etc. But the point is that hal implies a regression for many (most?) users. It provides no new (visible) funcionality, but adds complexity and lots of bugs by making auto-configuration override previous local configuration. That's got to be wrong. hal breaks existing working configurations without warnings. The simple test case is using a non-US keyboard properly configured as such in xorg.conf. Introduce evdev/hal and watch users get frustrated. The problem of course: keyboard layout cannot be auto-configured. But why ignore existing configuration? I still haven't got a clue how to really fix this, but have resorted to this for now: ?xml version=1.0 encoding=UTF-8? deviceinfo version=0.2 device match key=info.capabilities contains=input.keyboard merge key=input.xkb.model type=stringpc105/merge merge key=input.xkb.layout type=stringno/merge /match /device /deviceinfo IMHO, this is an ugly hack. I never wanted to configure hal. I wanted to configure X. In fact, I already had a working X configuration so I didn't expect to configure anything at all... Yes, I expected things to just work, given that it did prior to using evdev/hal. hal broke that expectation. The same goes for the suspend/resume support. I have an existing working configuration, using acpi-support and pm-utils. There is absolutely no upside to me moving this to hal and some power-daemon. It just obfuscates the configuration, making GUI configuration utilities mandatory and leaving me reading c++ bloat instead of some simple shell script to find out why things didn't work as expected. Just my .02 € as an ordinary user. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Wed, 2009-04-15 at 10:25 +0200, Bjørn Mork wrote: Well, you can always argue that the rest can be fixed. Provide patches etc. But the point is that hal implies a regression for many (most?) users. please stop the FUD. hal breaks existing working configurations without warnings. The simple test case is using a non-US keyboard properly configured as such in xorg.conf. Introduce evdev/hal and watch users get frustrated. The problem of course: keyboard layout cannot be auto-configured. But why ignore existing configuration? we don't ignore existing keymap configuration, and you get the same layout after the upgrade as was configured in xorg.conf. I still haven't got a clue how to really fix this, but have resorted to this for now: ?xml version=1.0 encoding=UTF-8? deviceinfo version=0.2 device match key=info.capabilities contains=input.keyboard merge key=input.xkb.model type=stringpc105/merge merge key=input.xkb.layout type=stringno/merge /match /device /deviceinfo IMHO, this is an ugly hack. I never wanted to configure hal. that's fine, you don't have to. I wanted to configure X. In fact, I already had a working X configuration so I didn't expect to configure anything at all... Yes, I expected things to just work, given that it did prior to using evdev/hal. hal broke that expectation. no, it didn't. you're just spreading nonsense. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Le mercredi 15 avril 2009 à 10:25 +0200, Bjørn Mork a écrit : False. All users want all things to work. The just is nice to have, but not important. It's infinitely better to have to configure things than not being able to. Bullshit. This is just true for nerds who want to spend their whole time tweaking their computers. Remember, there are also people who use them as tools. hal breaks existing working configurations without warnings. The simple test case is using a non-US keyboard properly configured as such in xorg.conf. Introduce evdev/hal and watch users get frustrated. The problem of course: keyboard layout cannot be auto-configured. But why ignore existing configuration? Existing configuration is not ignored. If you encounter a problem during the upgrade, you can just send a bug report to console-setup; the bug that occurred on my system was fixed in two days by the maintainers, so you can’t say they ignore issues. The same goes for the suspend/resume support. I have an existing working configuration, using acpi-support and pm-utils. There is absolutely no upside to me moving this to hal and some power-daemon. It just obfuscates the configuration, making GUI configuration utilities mandatory and leaving me reading c++ bloat instead of some simple shell script to find out why things didn't work as expected. If the only thing you want is suspend/resume, you can replace the power daemon with a simple script that talks to HAL using D-Bus. You would also be disappointed at reading what the “C++ bloat” does on this matter. Just my .02 € as an ordinary user. Ordinary users don’t read shell scripts to find out why things don’t work as expected. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
2009/4/12 Raphael Hertzog hert...@debian.org: Expect grumpy people every time that you add something new that they have to learn. I also had troubles with hal and X when I tried the X servers in experimental. But I have not read any serious criticism based on technical facts in the bug report you showed. I don't know if the fact that hal has 65 (sixty-five) outstanding bugs (many of which lay unanswered, some since YEARS), plus 10 forwarded bugs, qualifies as technical. But it's a fact. And not of the most pleasing kind. An other fact is that there is quite a big effort in the linux community to achieve fast start up, since this will strongly push linux spread on small devices like palmtops or netbooks. Hal is often horribly slow to start, spending several seconds in no-ops, just waiting for things to happen. A third fact is: if there's something new to learn, ok, it takes time but it's always good. But I'll need documentation. Basically the only documentation in the hal package are these lines: quote HAL is a hardware abstraction layer See http://www.freedesktop.org/Software/hal for lots of documentation, mailing lists, etc. unquote Please note that at that address there are NOT lots of documentation. There is something, mostly aimed at programmers. (The hal-doc package, as well, contains documentation for the APIs) I'm a user, pleased when things just work. I'm less pleased when I have to configure things to make then work, but I still feel it's ok. When I have to depend on a piece of software that either works on it's own, or it's impossible to configure, I start looking for that well-known coloured window logo. And I don't feel it's ok. This is just my personal experience with hal; an experience that makes me nostalgic of linux a couple of years ago. But I kind of feel I'm not alone. Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Wed, Apr 15, 2009 at 05:58:49PM +0200, Luca Niccoli lultimou...@gmail.com wrote: 2009/4/12 Raphael Hertzog hert...@debian.org: Expect grumpy people every time that you add something new that they have to learn. I also had troubles with hal and X when I tried the X servers in experimental. But I have not read any serious criticism based on technical facts in the bug report you showed. I don't know if the fact that hal has 65 (sixty-five) outstanding bugs (many of which lay unanswered, some since YEARS), plus 10 forwarded bugs, qualifies as technical. Bug count is not a good metric. Take a look at the bug count for linux-2.6, glibc, iceweasel... Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
[not CC-ing the RFA, I did it by mistake before and I don't think this is so relevant to that specific matter] 2009/4/15 Mike Hommey m...@glandium.org: Bug count is not a good metric. Take a look at the bug count for linux-2.6, glibc, iceweasel... Fair enough. Is there a convenient way to measure how long a bug stays unanswered? Or could someone suggest a better metric? Because I have the feeling that many hal bugs are just kept undealt (upstream as well), way more than with other packages, but it could be just a feeling of course. Anyway, I take back that point; I stand with the others: I do think hal is an obscure, user unfriendly, hardly configurable system. I see it is where a part of the community is heading, so we'll have to live with that, until something better pops up; but users shouldn't be forced to use it, when it isn't necessary. I don't want my X server to wai 30 seconds to start, because it has to wait for hal, when the rest of the system is ready in less then 10 seconds. I feel xorg.conf it's a neat way to configure it, because I can do it with a text editor, and I don't have all those XML tags in the way. If I'll need sophisticated hot-plugging, I'll switch; but as long as I don't need the feature, I don't want to pay the price, as Arjan van de Ven put it. Cheers, Luca -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Julien Cristau jcris...@debian.org writes: On Wed, 2009-04-15 at 10:25 +0200, Bjørn Mork wrote: Well, you can always argue that the rest can be fixed. Provide patches etc. But the point is that hal implies a regression for many (most?) users. please stop the FUD. Sorry. You're right. That was uncalled for. The introduction of hal has caused a few new problems for me, but I don't know anything about most users. My list of hal related regressions are a) laptop keys remapped or disappearing (might be caused by the driver - I don't know) b) unwanted auto-mounting c) the keyboard problem described below hal breaks existing working configurations without warnings. The simple test case is using a non-US keyboard properly configured as such in xorg.conf. Introduce evdev/hal and watch users get frustrated. The problem of course: keyboard layout cannot be auto-configured. But why ignore existing configuration? we don't ignore existing keymap configuration, and you get the same layout after the upgrade as was configured in xorg.conf. OK. I did not. But I guess that's something that's changed with recent console-setup changes? Some testing now reveals that you're right: I now get a Norwegian keyboard layout for every keyboard like device no matter what I write in xorg.conf. That's still confusing to me. I did manage to locate the settings in /etc/default/console-setup. But it's still unclear how to handle multiple input devices using this facility. Not that it matters much, but I find it a bit strange that the ThinkPad Extra Buttons and Video Bus devices are configured as 105 keys keyboards with Norwegian layout: (**) ThinkPad Extra Buttons: always reports core events (**) ThinkPad Extra Buttons: Device: /dev/input/event8 (II) ThinkPad Extra Buttons: Found keys (II) ThinkPad Extra Buttons: Configuring as keyboard (II) XINPUT: Adding extended input device ThinkPad Extra Buttons (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model pc105 (**) Option xkb_layout no (**) Option xkb_options lv3:ralt_switch (II) config/hal: Adding input device AT Translated Set 2 keyboard (**) AT Translated Set 2 keyboard: always reports core events (**) AT Translated Set 2 keyboard: Device: /dev/input/event1 (II) AT Translated Set 2 keyboard: Found keys (II) AT Translated Set 2 keyboard: Configuring as keyboard (II) XINPUT: Adding extended input device AT Translated Set 2 keyboard (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model pc105 (**) Option xkb_layout no (**) Option xkb_options lv3:ralt_switch (II) config/hal: Adding input device Video Bus (**) Video Bus: always reports core events (**) Video Bus: Device: /dev/input/event5 (II) Video Bus: Found keys (II) Video Bus: Configuring as keyboard (II) XINPUT: Adding extended input device Video Bus (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model pc105 (**) Option xkb_layout no (**) Option xkb_options lv3:ralt_switch I still haven't got a clue how to really fix this, but have resorted to this for now: ?xml version=1.0 encoding=UTF-8? deviceinfo version=0.2 device match key=info.capabilities contains=input.keyboard merge key=input.xkb.model type=stringpc105/merge merge key=input.xkb.layout type=stringno/merge /match /device /deviceinfo IMHO, this is an ugly hack. I never wanted to configure hal. that's fine, you don't have to. You're right. This seems to be taken care of by console-setup now. It was not when I created this file (which I did not do just for fun, although writing XML config files is my idea of a fun night :-) I wanted to configure X. In fact, I already had a working X configuration so I didn't expect to configure anything at all... Yes, I expected things to just work, given that it did prior to using evdev/hal. hal broke that expectation. no, it didn't. you're just spreading nonsense. I think we might have different interpretations of work. Suddenly ignoring xorg.conf changes in favour of a new config file without any clear (to me at least) indication how to restore previous behaviour is 1) unexpected 2) broken IMHO. You are of course free to have a different opinion. I just wanted to register mine. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Sun, 12 Apr 2009 15:15:56 +0200 Raphael Hertzog hert...@debian.org wrote: That said, it looks like that having things just work on the desktop require hal anyway and I fail to see why we would have to reinvent other solutions (like continuing to maintain/create many hacks in acpi-support) when we could centralize the knowledge in one place. What's the connection between ACPI and The Desktop? Could you outline the use-case HAL satisfies with regard to ACPI? Cheers, harry signature.asc Description: PGP signature
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Mon, Apr 06, 2009 at 09:55:39PM +0200, Michael Biebl wrote: As (co-)maintainer of pm-utils and hal, I'd prefer if we could work towards standardizing on one power management stack in Debian (and not install 3 by default [1]), i.e. I'd support in phasing out acpi-support and would gladly accept patches for hal and pm-utils which add (if there are) any missing bits from acpi-support. Not sure whether most users agree after reading #515214. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: mes...@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Sun, 2009-04-12 at 14:04 +0200, Michael Meskes wrote: On Mon, Apr 06, 2009 at 09:55:39PM +0200, Michael Biebl wrote: As (co-)maintainer of pm-utils and hal, I'd prefer if we could work towards standardizing on one power management stack in Debian (and not install 3 by default [1]), i.e. I'd support in phasing out acpi-support and would gladly accept patches for hal and pm-utils which add (if there are) any missing bits from acpi-support. Not sure whether most users agree after reading #515214. 515214 isn't most users. most users just want things to work. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Sun, Apr 12, 2009 at 01:11:26PM +0100, Julien Cristau wrote: 515214 isn't most users. most users just want things to work. But then 515214 appears to be at least a significant amount of users. Anyway, having things just work and being able to run a system without hal do not contradict each other. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: mes...@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Sun, 2009-04-12 at 15:01 +0200, Michael Meskes wrote: On Sun, Apr 12, 2009 at 01:11:26PM +0100, Julien Cristau wrote: 515214 isn't most users. most users just want things to work. But then 515214 appears to be at least a significant amount of users. Anyway, no, it doesn't. having things just work and being able to run a system without hal do not contradict each other. in this case, yes they do. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Sun, 12 Apr 2009, Michael Meskes wrote: But then 515214 appears to be at least a significant amount of users. Anyway, having things just work and being able to run a system without hal do not contradict each other. Expect grumpy people every time that you add something new that they have to learn. I also had troubles with hal and X when I tried the X servers in experimental. But I have not read any serious criticism based on technical facts in the bug report you showed. That said, it looks like that having things just work on the desktop require hal anyway and I fail to see why we would have to reinvent other solutions (like continuing to maintain/create many hacks in acpi-support) when we could centralize the knowledge in one place. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Sun, 12 Apr 2009 13:11:26 +0100, Julien Cristau jcris...@debian.org wrote: 515214 isn't most users. most users just want things to work. While were at it, I find it unacceptable to set a bug wontfix without explanation. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
[Michael Biebl] As (co-)maintainer of pm-utils and hal, I'd prefer if we could work towards standardizing on one power management stack in Debian (and not install 3 by default [1]), i.e. I'd support in phasing out acpi-support and would gladly accept patches for hal and pm-utils which add (if there are) any missing bits from acpi-support. Perhaps hotkey-setup should be made obsolete too? Is it still work keeping? URL: http://packages.qa.debian.org/h/hotkey-setup.html . Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Tue, Apr 07, 2009 at 01:26:18PM +0200, Petter Reinholdtsen wrote: [Michael Biebl] As (co-)maintainer of pm-utils and hal, I'd prefer if we could work towards standardizing on one power management stack in Debian (and not install 3 by default [1]), i.e. I'd support in phasing out acpi-support and would gladly accept patches for hal and pm-utils which add (if there are) any missing bits from acpi-support. Perhaps hotkey-setup should be made obsolete too? Is it still work keeping? URL: http://packages.qa.debian.org/h/hotkey-setup.html . That is also being phased out in Ubuntu. The only remaining functionality in that package for jaunty is setting /proc/acpi/video/*/DOS; we need to either confirm that this is handled somewhere else or determine an appropriate package to set this by default before dropping hotkey-setup. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote: I'm putting the acpi-support package up for adoption. The RFA bug is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522683 Given that I already maintain acpid in pkg-acpi, I'm very interested. And yes, the acpi team will welcome new members who like to help too. :-) Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: mes...@jabber.org Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Hi Steve, On Mon, April 6, 2009 05:44, Steve Langasek wrote: On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote: 1. The upstream for this package is Ubuntu. Ubuntu has never been very cooperative at accepting changes, until recently: our contact Steve Langasek has indicated that he is interested in merging most or all of our changes, provided that we send them in in chunks, with proper rationales. I have to say here in defense of Ubuntu that I don't see any record of these patches being submitted to the Ubuntu package via Launchpad, which, since Ubuntu does not have individual package maintainers, is the only reliable way to ensure that proposed changes are seen and considered by the people working on the package at any given time. Yeah, I think it's probably mostly me being disappointed earlier, and not so much the Ubuntu side. The feeling that I have had is that because there are no individual package maintainers, it's hard to find somebody on the other side who feels responsible for the package, and who is willing to discuss merging of sets of patches etc., so that you can discuss the chances of acceptance _before_ you do the work. It's so much easier if you can talk to a person, launchpad sometimes feels like throwing stuff into a black hole. /rant Things suddenly got much easier when I got into direct contact with you. But I shouldn't be blaming Ubuntu, my expectations just didn't match the way Ubuntu works. I don't have time to work on the Debian package myself (either as maintainer or for sifting through the delta between Debian and Ubuntu), but I definitely am happy to accept fixes upstream in reasonable-sized chunks. Anyway, as Bart points out, there's another issue: 4. Ubuntu is PHASING OUT this package. They have already moved suspend to pm-utils (but have failed to remove suspend support from acpi-support). They're currently moving hotkey translation to hal. This means that soon we will have no upstream that we can follow! Or we should ensure that Ubuntu's hal changes are included in our version of hal as well -- no clue how those packages are related, or whether Ubuntu's changes are going into upstream hal. Since the last time I had a chance to speak with Bart about this, there's been quite a bit of progress on phasing out the package for Ubuntu; in jaunty, we've dropped a number of quirk scripts related to suspend/resume, as well as close to 30 of the ACPI event-handling scripts from /etc/acpi - basically: all those scripts that were being used to synthesize key events (which doesn't work with recent kernels anyway) and which we could verify were being handled by hal. And yes, Martin Pitt works very closely with hal upstream to ensure fixes are incorporated. Thanks for the update! Cheers, Bart -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Michael Meskes wrote: On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote: I'm putting the acpi-support package up for adoption. The RFA bug is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522683 Given that I already maintain acpid in pkg-acpi, I'm very interested. And yes, the acpi team will welcome new members who like to help too. :-) Thanks for helping out! It sounds like a very good plan to move acpi-support to the acpi team. I will do what's necessary to transfer maintainership to you, I'll keep you informed of the progress. Cheers, Bart -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Mon, 06 Apr 2009, Bart Samwel wrote: black hole. /rant Things suddenly got much easier when I got into direct contact with you. But I shouldn't be blaming Ubuntu, my expectations just didn't match the way Ubuntu works. To be fair, I proposed co-maintenance to Matthew Garrett when I integrated acpi-support in Debian and wanted him to use bzr or something so that we could better collaborate but at that time he was already telling me that acpi-support should/will die and he wasn't interested in setting up something more complicated than change upload. I didn' went further to try to collaborate and at that time was packaging it mostly as a follower of Ubuntu but bugs did accumulate until Bart took it over. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Steve Langasek wrote: On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote: 1. The upstream for this package is Ubuntu. Ubuntu has never been very cooperative at accepting changes, until recently: our contact Steve Langasek has indicated that he is interested in merging most or all of our changes, provided that we send them in in chunks, with proper rationales. I have to say here in defense of Ubuntu that I don't see any record of these patches being submitted to the Ubuntu package via Launchpad, which, since Ubuntu does not have individual package maintainers, is the only reliable way to ensure that proposed changes are seen and considered by the people working on the package at any given time. I don't have time to work on the Debian package myself (either as maintainer or for sifting through the delta between Debian and Ubuntu), but I definitely am happy to accept fixes upstream in reasonable-sized chunks. Anyway, as Bart points out, there's another issue: 4. Ubuntu is PHASING OUT this package. They have already moved suspend to pm-utils (but have failed to remove suspend support from acpi-support). They're currently moving hotkey translation to hal. This means that soon we will have no upstream that we can follow! Or we should ensure that Ubuntu's hal changes are included in our version of hal as well -- no clue how those packages are related, or whether Ubuntu's changes are going into upstream hal. Since the last time I had a chance to speak with Bart about this, there's been quite a bit of progress on phasing out the package for Ubuntu; in jaunty, we've dropped a number of quirk scripts related to suspend/resume, as well as close to 30 of the ACPI event-handling scripts from /etc/acpi - basically: all those scripts that were being used to synthesize key events (which doesn't work with recent kernels anyway) and which we could verify were being handled by hal. And yes, Martin Pitt works very closely with hal upstream to ensure fixes are incorporated. I can confirm that. Martin is doing an awesome job, submitting patches upstream or to Debian ftm. As (co-)maintainer of pm-utils and hal, I'd prefer if we could work towards standardizing on one power management stack in Debian (and not install 3 by default [1]), i.e. I'd support in phasing out acpi-support and would gladly accept patches for hal and pm-utils which add (if there are) any missing bits from acpi-support. Cheers, Michael [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451380 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Dear all, I'm putting the acpi-support package up for adoption. The RFA bug is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522683 I have copied the text of the bug report below (since my mail client did not allow me to set X-Debbugs-CC). If anyone is interested to adopt this package, please get in touch! Cheers, Bart -SNIP- I want to stop maintaining the acpi-support package and am looking for an adopter. This package is relatively high-profile, since it is installed by default on all laptops, and part of it is installed on all ACPI machines. There are some specific challenges with the package that make it interesting to maintain, for some value of interesting. The package provides the following: 1. Power button support for all systems, in the form of package acpi-support-base. 2. Button support for laptops. Special laptop button translations are included for various laptop brands and types. This also includes default scripts for button functionality for some laptops, including wireless buttons etc. 3. Suspend/resume support. Acpi-support used to be one of the primary suspend packages, before pm-utils came along. Right now, it still contains the suspend logic, but in the default configuration it delegates any suspend requests to pm-utils. Still, the legacy suspend support should keep working for now. This package receives a pretty steady stream of bug reports due to new hardware with new button quirks, and it requires active maintenance. There are several challenges involved in maintaining this package: 1. The upstream for this package is Ubuntu. Ubuntu has never been very cooperative at accepting changes, until recently: our contact Steve Langasek has indicated that he is interested in merging most or all of our changes, provided that we send them in in chunks, with proper rationales. 2. Even though we have an upstream, we build the package as a Debian-native package, since we have extensively changed the package. We moved files around etc., and specifying an upstream source tarball results in an incorrect package being built. :-/ 3. Changes from the upstream are extensive: - We build two packages: acpi-support-base and acpi-support. The upstream builds only one, for laptops only. - We have support for suspend methods, i.e., we can delegate suspend to pm-utils but we can also handle it ourselves, depending on configuration. - A very large variety of small changes have been made as well, in response to bug reports. None of these changes have been sent upstream. :-/ 4. Ubuntu is PHASING OUT this package. They have already moved suspend to pm-utils (but have failed to remove suspend support from acpi-support). They're currently moving hotkey translation to hal. This means that soon we will have no upstream that we can follow! Or we should ensure that Ubuntu's hal changes are included in our version of hal as well -- no clue how those packages are related, or whether Ubuntu's changes are going into upstream hal. 5. The kernel is adding more and more native support for these buttons, so that acpi-support does not need to translate them anymore. In the end, the package may need phasing out in Debian as well, or it may need to become the upstream instead of Ubuntu, in which case it requires extra maintenance. Whatever happens, it will be a challenge to keep all hardware working properly. Whoever adopts this package will help to keep extremely large numbers of laptop users happy! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Sun, Apr 05, 2009 at 11:06:15PM +0200, Bart Samwel wrote: 1. The upstream for this package is Ubuntu. Ubuntu has never been very cooperative at accepting changes, until recently: our contact Steve Langasek has indicated that he is interested in merging most or all of our changes, provided that we send them in in chunks, with proper rationales. I have to say here in defense of Ubuntu that I don't see any record of these patches being submitted to the Ubuntu package via Launchpad, which, since Ubuntu does not have individual package maintainers, is the only reliable way to ensure that proposed changes are seen and considered by the people working on the package at any given time. I don't have time to work on the Debian package myself (either as maintainer or for sifting through the delta between Debian and Ubuntu), but I definitely am happy to accept fixes upstream in reasonable-sized chunks. Anyway, as Bart points out, there's another issue: 4. Ubuntu is PHASING OUT this package. They have already moved suspend to pm-utils (but have failed to remove suspend support from acpi-support). They're currently moving hotkey translation to hal. This means that soon we will have no upstream that we can follow! Or we should ensure that Ubuntu's hal changes are included in our version of hal as well -- no clue how those packages are related, or whether Ubuntu's changes are going into upstream hal. Since the last time I had a chance to speak with Bart about this, there's been quite a bit of progress on phasing out the package for Ubuntu; in jaunty, we've dropped a number of quirk scripts related to suspend/resume, as well as close to 30 of the ACPI event-handling scripts from /etc/acpi - basically: all those scripts that were being used to synthesize key events (which doesn't work with recent kernels anyway) and which we could verify were being handled by hal. And yes, Martin Pitt works very closely with hal upstream to ensure fixes are incorporated. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
