From arvidjaar at mail.ru Sun May 1 11:10:49 2005 From: arvidjaar at mail.ru (Andrey Borzenkov) Date: Mon Aug 15 18:49:23 2005 Subject: 0.4.7 - hald/kernel race in checking for USB stick partition table In-Reply-To: <20050419024517.GA7494@imp.flyn.org> References: <20050419024517.GA7494@imp.flyn.org> Message-ID: <200505012210.57290.arvidjaar@mail.ru> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Mon May 2 10:19:04 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:23 2005 Subject: fstab symlink problems [was: VolumeUnmountForced symlink problem] In-Reply-To: <200504301412.24281.rohan.pm@gmail.com> References: <200504261525.14649.rohan.pm@gmail.com> <200504291515.52366.rohan.pm@gmail.com> <1114810910.14228.21.camel@daxter.boston.redhat.com> <200504301412.24281.rohan.pm@gmail.com> Message-ID: <1115054344.3195.5.camel@daxter.boston.redhat.com> On Sat, 2005-04-30 at 14:12 +1000, Rohan McGovern wrote: > Behaviour is improved, e.g. HAL now updates volume.is_mounted when you mount a > device using a symbolic link. The original problem still exists however (HAL > unmounts devices mounted with actual device nodes, but not those mounted with > symlinks). Right, I've fixed this too (we lazy unmount from both the daemon and the helper). Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Mon May 2 10:37:16 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:23 2005 Subject: 0.4.7 - hald/kernel race in checking for USB stick partition table In-Reply-To: <200505012210.57290.arvidjaar@mail.ru> References: <20050419024517.GA7494@imp.flyn.org> <200505012210.57290.arvidjaar@mail.ru> Message-ID: <1115055436.3195.14.camel@daxter.boston.redhat.com> Hi, On Sun, 2005-05-01 at 22:10 +0400, Andrey Borzenkov wrote: > See Mandrake bug > > What apparently happens to original poster - his USB stick has both partition > 1 and something that looks very much like VFAT signature in block 0 together > with valid partition table (I do not know, may be this VFAT superblock even > points to the same physical location as that in partition 1). And it is a bit > slow before it can be accessed. > > So when hald does initial detect_media(), no partition has yet been detected > by kernel (at least, hald did not yet get any hotplug event for it), so it > assumes non-partitioned device and goes ahead with detecting filesystem. And > it really finds one. Next comes partition hotplug event from kernel and it > creates second mount point for partition. > > Why none of them gets mounted I am not sure, may be HAL gets confused at this > point. > > What would be the proper fix? The most simple one seems to add MSDOS partition > detection to volume_id_probe(..., VOLUME_ID_ALL, ...); what side effects may > it have? > > Apparently the same problem exists in 0.5.1 too for all I can tell. It looks to me like the USB memory stick is formatted in a way that confuses hal. To solve this, it would be useful to have the contents of 'hald --daemon=no --verbose=yes' cf. http://freedesktop.org/wiki/Software_2fHalTraces Also, it is not clear to me how the user formatted his USB memory stick - is the file system supposed to be on /dev/sda or /dev/sda1? It looks from the dd dump of the first two sectors here http://qa.mandriva.com/attachment.cgi?id=2964 that it's supposed to be on /dev/sda; maybe the kernel gets it wrong since it sends /dev/sda1? Or maybe hal gets it wrong. Kay, do you know? One way to work around this would be to write zeros all over the stick and repartition and reformat it. It would be better though to fix hal as far as that is possible. HTH, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From piggz1 at gmail.com Thu May 5 07:46:44 2005 From: piggz1 at gmail.com (Adam Pigg) Date: Mon Aug 15 18:49:23 2005 Subject: Trouble building hal >=0.5 Message-ID: <200505051546.48347.adam@piggz.co.uk> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From dcbw at redhat.com Thu May 5 09:01:48 2005 From: dcbw at redhat.com (Dan Williams) Date: Mon Aug 15 18:49:23 2005 Subject: Trouble building hal >=0.5 In-Reply-To: <200505051546.48347.adam@piggz.co.uk> References: <200505051546.48347.adam@piggz.co.uk> Message-ID: <1115308908.16211.31.camel@dcbw.boston.redhat.com> On Thu, 2005-05-05 at 15:46 +0100, Adam Pigg wrote: > Hi > > I havnt been able to build hal since 0.5. I just tried 0.5.1 and got the same > result. > > Im pretty sure dbus is installed ok (0.33). > > Ive included the dbus install, the result of 'locate dbus' to check there are > no previous installations and the result of the hal build. > > Gcc is: > [root@enterprise init.d]# gcc -v > Reading specs from /usr/lib/gcc/i586-mandrake-linux-gnu/3.4.3/specs > Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib > --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info > --enable-shared --enable-threads=posix --disable-checking --enable-long-long > --enable-__cxa_atexit --enable-clocale=gnu --disable-libunwind-exceptions > --enable-languages=c,c++,ada,f77,objc,java --host=i586-mandrake-linux-gnu > --with-system-zlib > Thread model: posix > gcc version 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk) > > Hope someone can suggest something What's the actual HAL failure? Can you attach the output of the HAL build up to the point of failure? Dan _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From piggz1 at gmail.com Thu May 5 09:26:31 2005 From: piggz1 at gmail.com (Adam Pigg) Date: Mon Aug 15 18:49:23 2005 Subject: Trouble building hal >=0.5 In-Reply-To: <1115308908.16211.31.camel@dcbw.boston.redhat.com> References: <200505051546.48347.adam@piggz.co.uk> <1115308908.16211.31.camel@dcbw.boston.redhat.com> Message-ID: <200505051726.35249.adam@piggz.co.uk> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From dcbw at redhat.com Thu May 5 09:37:01 2005 From: dcbw at redhat.com (Dan Williams) Date: Mon Aug 15 18:49:23 2005 Subject: Trouble building hal >=0.5 In-Reply-To: <200505051726.35249.adam@piggz.co.uk> References: <200505051546.48347.adam@piggz.co.uk> <1115308908.16211.31.camel@dcbw.boston.redhat.com> <200505051726.35249.adam@piggz.co.uk> Message-ID: <1115311021.16211.41.camel@dcbw.boston.redhat.com> On Thu, 2005-05-05 at 17:26 +0100, Adam Pigg wrote: > I thoguh i had included the failure but it seems to be just part of it...here > it is again > > cheers Can you attach your copy of: /usr/local/include/dbus-1.0/dbus/dbus-types.h to another mail? Dan _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From piggz1 at gmail.com Thu May 5 11:13:58 2005 From: piggz1 at gmail.com (Adam Pigg) Date: Mon Aug 15 18:49:23 2005 Subject: Trouble building hal >=0.5 In-Reply-To: <1115311021.16211.41.camel@dcbw.boston.redhat.com> References: <200505051546.48347.adam@piggz.co.uk> <200505051726.35249.adam@piggz.co.uk> <1115311021.16211.41.camel@dcbw.boston.redhat.com> Message-ID: <200505051914.06761.adam@piggz.co.uk> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From dcbw at redhat.com Thu May 5 11:52:29 2005 From: dcbw at redhat.com (Dan Williams) Date: Mon Aug 15 18:49:23 2005 Subject: Trouble building hal >=0.5 In-Reply-To: <200505051914.06761.adam@piggz.co.uk> References: <200505051546.48347.adam@piggz.co.uk> <200505051726.35249.adam@piggz.co.uk> <1115311021.16211.41.camel@dcbw.boston.redhat.com> <200505051914.06761.adam@piggz.co.uk> Message-ID: <1115319149.3406.2.camel@dcbw.boston.redhat.com> On Thu, 2005-05-05 at 19:13 +0100, Adam Pigg wrote: > Here you go > > Cheers I think your problem is that the installation of dbus was incorrect. The file /usr/local/include/dbus-1.0/dbus/dbus-arch-deps.h probably needs to be here: /usr/lib/dbus-1.0/include/dbus/dbus-arch-deps.h You should also verify that line 30 of dbus-arch-deps.h is: #include Dan _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From piggz1 at gmail.com Thu May 5 13:22:49 2005 From: piggz1 at gmail.com (Adam Pigg) Date: Mon Aug 15 18:49:23 2005 Subject: Trouble building hal >=0.5 In-Reply-To: <1115319149.3406.2.camel@dcbw.boston.redhat.com> References: <200505051546.48347.adam@piggz.co.uk> <200505051914.06761.adam@piggz.co.uk> <1115319149.3406.2.camel@dcbw.boston.redhat.com> Message-ID: <200505052122.52689.adam@piggz.co.uk> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From dcbw at redhat.com Thu May 5 14:03:19 2005 From: dcbw at redhat.com (Dan Williams) Date: Mon Aug 15 18:49:23 2005 Subject: Trouble building hal >=0.5 In-Reply-To: <200505052122.52689.adam@piggz.co.uk> References: <200505051546.48347.adam@piggz.co.uk> <200505051914.06761.adam@piggz.co.uk> <1115319149.3406.2.camel@dcbw.boston.redhat.com> <200505052122.52689.adam@piggz.co.uk> Message-ID: <1115326999.8099.5.camel@dcbw.boston.redhat.com> On Thu, 2005-05-05 at 21:22 +0100, Adam Pigg wrote: > Cool, moving that file seems to have done the trick > > it seems a bit strange that the dbus install seemed to go ok Might have been a missing --libdir or some other dir option on the dbus configure line. Dan _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From drzeus-list at drzeus.cx Sat May 7 15:49:31 2005 From: drzeus-list at drzeus.cx (Pierre Ossman) Date: Mon Aug 15 18:49:23 2005 Subject: MMC support in hal Message-ID: <427D45FB.1020407@drzeus.cx> I've finally gotten around to upgrading my system to the new dbus so that I can run the latest hal. So now I've been able to test the MMC patch I submitted a while back =) It seems to work just fine. hdm doesn't seem to handle the mmc bus nicely though. And the 10-storage-policy.fdi needs an addition for fstab-sync to do its magic. But other than that, everything is peachy =) So David, if you could fix the storage policy for the next release, that would be great. hdm isn't as critical. At least not for me. Rgds Pierre _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Sun May 8 11:32:31 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:23 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec Message-ID: <1115577151.3201.4.camel@localhost.localdomain> According to the HAL spec, battery.present is compulsory for devices that have capability battery. Whilst programming the tooltip logic for Power Manager, I noticed that battery.present is never set for my UPS. It makes no sense to have a UPS without a battery (you can't hot-change the batteries...) so this parameter should be hard-coded. Patch attached. Thanks, Richard. -------------- next part -------------- A non-text attachment was scrubbed... Name: ups-always-present.patch Type: text/x-patch Size: 410 bytes Desc: not available Url : http://lists.freedesktop.org/archives/hal/attachments/20050508/e343985a/ups-always-present.bin -------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From drzeus-list at drzeus.cx Sun May 8 13:17:07 2005 From: drzeus-list at drzeus.cx (Pierre Ossman) Date: Mon Aug 15 18:49:23 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115577151.3201.4.camel@localhost.localdomain> References: <1115577151.3201.4.camel@localhost.localdomain> Message-ID: <427E73C3.7090100@drzeus.cx> Richard Hughes wrote: > According to the HAL spec, battery.present is compulsory for devices > that have capability battery. > > Whilst programming the tooltip logic for Power Manager, I noticed that > battery.present is never set for my UPS. It makes no sense to have a UPS > without a battery (you can't hot-change the batteries...) so this > parameter should be hard-coded. > > Even though I've never seen a UPS capable of hot-swapping the batteries, I don't see why that wouldn't be possible. :) Could be useful on high-reliability systems. As for the usefulness of an UPS without battery. They are usually pretty good filters for line noise. But you normally keep the batteries in them even if they're crappy in those cases. Just my $.02 Rgds Pierre _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From pat at suwalski.net Sun May 8 13:20:58 2005 From: pat at suwalski.net (Pat Suwalski) Date: Mon Aug 15 18:49:23 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <427E73C3.7090100@drzeus.cx> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> Message-ID: <427E74AA.5080609@suwalski.net> Pierre Ossman wrote: > Even though I've never seen a UPS capable of hot-swapping the batteries, > I don't see why that wouldn't be possible. :) > Could be useful on high-reliability systems. All the rack-mount UPS units I have ever seen support this feature. There is no need for special cases for this or anything, the batteries don't need "unlocking" or anything, it's handled just like laptop batteries. > As for the usefulness of an UPS without battery. They are usually pretty > good filters for line noise. But you normally keep the batteries in them > even if they're crappy in those cases. Even the deadest sealed-lead-acid cells in a UPS unit will hold the power for at least 2 seconds, which is great for fancy power-conditioning. Either way, no special handling is required. --Pat _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Sun May 8 13:53:21 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:23 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <427E74AA.5080609@suwalski.net> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> Message-ID: <1115585601.3201.10.camel@localhost.localdomain> On Sun, 2005-05-08 at 16:20 -0400, Pat Suwalski wrote: > Pierre Ossman wrote: > > Even though I've never seen a UPS capable of hot-swapping the batteries, > > I don't see why that wouldn't be possible. :) > > Could be useful on high-reliability systems. > > All the rack-mount UPS units I have ever seen support this feature. Ohh, didn't know that. Sorry. > There is no need for special cases for this or anything, the batteries > don't need "unlocking" or anything, it's handled just like laptop batteries. What's the best way to enforce this for UPS's that don't report "I'm present?" > Even the deadest sealed-lead-acid cells in a UPS unit will hold the > power for at least 2 seconds, which is great for fancy power-conditioning. I know, my battery lasts about 40 seconds under full load - but I've seldom had a power cut greater than 1-2 seconds living in the UK. > Either way, no special handling is required. Also, I've noticed that UPS time to empty is measured in seconds on my UPS (and thus shows up as hours on GNOME Power Manager" as no conversion to minutes is done. Is this my rubbish UPS, or is this a bug in HAL? Thanks, Richard. _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From pat at suwalski.net Sun May 8 14:52:17 2005 From: pat at suwalski.net (Pat Suwalski) Date: Mon Aug 15 18:49:23 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115585601.3201.10.camel@localhost.localdomain> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> Message-ID: <427E8A11.904@suwalski.net> Richard Hughes wrote: >>There is no need for special cases for this or anything, the batteries >>don't need "unlocking" or anything, it's handled just like laptop batteries. > > What's the best way to enforce this for UPS's that don't report "I'm > present?" How do UPSs that don't report presence currently work? I was simply pointing out that battery management is typically handled by the UPS, much like it would be with APM or ACPI. >>Even the deadest sealed-lead-acid cells in a UPS unit will hold the >>power for at least 2 seconds, which is great for fancy power-conditioning. > > I know, my battery lasts about 40 seconds under full load - but I've > seldom had a power cut greater than 1-2 seconds living in the UK. Lucky. Hours over here. > Also, I've noticed that UPS time to empty is measured in seconds on my > UPS (and thus shows up as hours on GNOME Power Manager" as no conversion > to minutes is done. > Is this my rubbish UPS, or is this a bug in HAL? I can't comment on this, since I don't know the protocols. But it would be a major hitch if some UPSs using the same protocol reported times in different units. --Pat _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Sun May 8 20:52:40 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:23 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115577151.3201.4.camel@localhost.localdomain> References: <1115577151.3201.4.camel@localhost.localdomain> Message-ID: <1115610761.4833.4.camel@powerbook.fubar.dk> On Sun, 2005-05-08 at 19:32 +0100, Richard Hughes wrote: > According to the HAL spec, battery.present is compulsory for devices > that have capability battery. > > Whilst programming the tooltip logic for Power Manager, I noticed that > battery.present is never set for my UPS. I'm aware of this issue https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=151766 Note that with an old enough kernel this (and other values) are set correctly http://people.redhat.com/davidz/hal-hid-ups.png > It makes no sense to have a UPS > without a battery (you can't hot-change the batteries...) Actually it does though addon-hid-ups doesn't support it just yet. Should be easy though, patches are welcome :-). > so this > parameter should be hard-coded. > > Patch attached. OK, I suppose we can set it so it works with kernels that are borked too :-). Applied. David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Sun May 8 21:01:43 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:23 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115585601.3201.10.camel@localhost.localdomain> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> Message-ID: <1115611304.4833.12.camel@powerbook.fubar.dk> On Sun, 2005-05-08 at 21:53 +0100, Richard Hughes wrote: > What's the best way to enforce this for UPS's that don't report "I'm > present?" They would always report battery.is_present==TRUE I suppose. > Also, I've noticed that UPS time to empty is measured in seconds on my > UPS (and thus shows up as hours on GNOME Power Manager" as no conversion > to minutes is done. > Is this my rubbish UPS, or is this a bug in HAL? If the property battery.remaining_time is available (it's optional) it always mean number of seconds. I don't believe we set any other battery.* properties related to this - can you clarify please? Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Sun May 8 21:10:34 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:23 2005 Subject: MMC support in hal In-Reply-To: <427D45FB.1020407@drzeus.cx> References: <427D45FB.1020407@drzeus.cx> Message-ID: <1115611834.4833.15.camel@powerbook.fubar.dk> On Sun, 2005-05-08 at 00:49 +0200, Pierre Ossman wrote: > I've finally gotten around to upgrading my system to the new dbus so > that I can run the latest hal. So now I've been able to test the MMC > patch I submitted a while back =) > > It seems to work just fine. hdm doesn't seem to handle the mmc bus > nicely though. And the 10-storage-policy.fdi needs an addition for > fstab-sync to do its magic. But other than that, everything is peachy =) > > So David, if you could fix the storage policy for the next release, that > would be great. hdm isn't as critical. At least not for me. Does the attached patch work? Thanks, David -------------- next part -------------- A non-text attachment was scrubbed... Name: hal-0.5.1-add-mmc-policy.patch Type: text/x-patch Size: 821 bytes Desc: not available Url : http://lists.freedesktop.org/archives/hal/attachments/20050509/0357f145/hal-0.5.1-add-mmc-policy.bin -------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Sun May 8 23:39:05 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:23 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115611304.4833.12.camel@powerbook.fubar.dk> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> Message-ID: <1115620745.2984.12.camel@localhost.localdomain> On Mon, 2005-05-09 at 00:01 -0400, David Zeuthen wrote: > On Sun, 2005-05-08 at 21:53 +0100, Richard Hughes wrote: > If the property battery.remaining_time is available (it's optional) it > always mean number of seconds. I don't believe we set any other > battery.* properties related to this - can you clarify please? >From HAL spec: battery.remaining_time (int) No Remaining time, in seconds, that the battery can provide power if it's discharging. This is an estimate and may be imprecise. I assumed this was in minutes, *my* error, sorry for the noise. On an unrelated note, how keen are you to put the battery.remaining_time calculations inside addon-acpi.c? At the moment it does not calculate this value and leaves it to the application (which is okay, since it's non-compulsory...). I've looked about on the Internet and there appears to be one standard formula for charge/rate/last-full type calculations - I believe our original argument for not including the formula was that an application may have a "better" way of doing it. Maybe we should provide the "standard" answer? It's not that much hassle to work it out in an application, but takes away some of the nice abstraction (if battery = ACPI/ if battery = PMU is needed...) and would IMO be better put in the addon itself. Comments please :-) Richard. _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From drzeus-list at drzeus.cx Mon May 9 00:11:01 2005 From: drzeus-list at drzeus.cx (Pierre Ossman) Date: Mon Aug 15 18:49:23 2005 Subject: MMC support in hal In-Reply-To: <1115611834.4833.15.camel@powerbook.fubar.dk> References: <427D45FB.1020407@drzeus.cx> <1115611834.4833.15.camel@powerbook.fubar.dk> Message-ID: <427F0D05.4010206@drzeus.cx> David Zeuthen wrote: > >Does the attached patch work? > >Thanks, >David > > Perfectly =) _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Mon May 9 07:35:19 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:23 2005 Subject: MMC support in hal In-Reply-To: <427F0D05.4010206@drzeus.cx> References: <427D45FB.1020407@drzeus.cx> <1115611834.4833.15.camel@powerbook.fubar.dk> <427F0D05.4010206@drzeus.cx> Message-ID: <1115649319.4231.0.camel@daxter.boston.redhat.com> On Mon, 2005-05-09 at 09:11 +0200, Pierre Ossman wrote: > David Zeuthen wrote: > > > > >Does the attached patch work? > > > >Thanks, > >David > > > > > > Perfectly =) > Ok, I've committed this. Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Mon May 9 07:38:04 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:23 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115620745.2984.12.camel@localhost.localdomain> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> Message-ID: <1115649484.4231.3.camel@daxter.boston.redhat.com> On Mon, 2005-05-09 at 07:39 +0100, Richard Hughes wrote: > On an unrelated note, how keen are you to put the battery.remaining_time > calculations inside addon-acpi.c? At the moment it does not calculate > this value and leaves it to the application (which is okay, since it's > non-compulsory...). Okay, I suppose that it would be useful. It would be nice too if battery.remaining_time also was 'number of minutes until battery is fully charged' when battery.is_charging==TRUE. Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Mon May 9 07:40:39 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:23 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115649484.4231.3.camel@daxter.boston.redhat.com> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> Message-ID: <1115649639.4231.5.camel@daxter.boston.redhat.com> On Mon, 2005-05-09 at 10:38 -0400, David Zeuthen wrote: > On Mon, 2005-05-09 at 07:39 +0100, Richard Hughes wrote: > > On an unrelated note, how keen are you to put the battery.remaining_time > > calculations inside addon-acpi.c? At the moment it does not calculate > > this value and leaves it to the application (which is okay, since it's > > non-compulsory...). > > Okay, I suppose that it would be useful. It would be nice too if > battery.remaining_time also was 'number of minutes until battery is > fully charged' when battery.is_charging==TRUE. Bah, number of seconds. Sorry, still on my first cup. Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Mon May 9 09:27:54 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:23 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115649639.4231.5.camel@daxter.boston.redhat.com> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> Message-ID: <1115656074.3032.3.camel@localhost.localdomain> On Mon, 2005-05-09 at 10:40 -0400, David Zeuthen wrote: > On Mon, 2005-05-09 at 10:38 -0400, David Zeuthen wrote: > > On Mon, 2005-05-09 at 07:39 +0100, Richard Hughes wrote: > > > On an unrelated note, how keen are you to put the battery.remaining_time > > > calculations inside addon-acpi.c? At the moment it does not calculate > > > this value and leaves it to the application (which is okay, since it's > > > non-compulsory...). > > > > Okay, I suppose that it would be useful. It would be nice too if > > battery.remaining_time also was 'number of minutes until battery is > > fully charged' when battery.is_charging==TRUE. That's the logic that I'm using now: if (isCharging) minutesRemaining = ((double) (LastFull - Charge) / (double) Rate) * 60; else minutesRemaining = ((double) Charge / (double) Rate) * 60; > Bah, number of seconds. Sorry, still on my first cup. No problem. I'm trying to wean myself off coffee, and it hurts. I'll work on a patch. Thanks, Richard. _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Mon May 9 11:42:32 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:23 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115656074.3032.3.camel@localhost.localdomain> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> <1115656074.3032.3.camel@localhost.localdomain> Message-ID: <1115664152.3032.28.camel@localhost.localdomain> On Mon, 2005-05-09 at 17:28 +0100, Richard Hughes wrote: > I'll work on a patch. Attached, I know it's quick and dirty, but I wanted comments. How expensive is setting an int as a property, then getting it? Thanks, Richard. -------------- next part -------------- A non-text attachment was scrubbed... Name: hal-add-time-01.patch Type: text/x-patch Size: 1647 bytes Desc: not available Url : http://lists.freedesktop.org/archives/hal/attachments/20050509/13c4bc77/hal-add-time-01.bin -------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Mon May 9 12:09:40 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:24 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115664152.3032.28.camel@localhost.localdomain> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> <1115656074.3032.3.camel@localhost.localdomain> <1115664152.3032.28.camel@localhost.localdomain> Message-ID: <1115665781.4231.16.camel@daxter.boston.redhat.com> On Mon, 2005-05-09 at 19:42 +0100, Richard Hughes wrote: > On Mon, 2005-05-09 at 17:28 +0100, Richard Hughes wrote: > > > I'll work on a patch. > > Attached, I know it's quick and dirty, but I wanted comments. Propose to make a generic function in hald/util.c and use it for both APM, PMU and ACPI. > How > expensive is setting an int as a property, then getting it? Only rule is to not set it multiple times as each time setting it will emit a notification. David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Mon May 9 12:14:38 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:24 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115665781.4231.16.camel@daxter.boston.redhat.com> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> <1115656074.3032.3.camel@localhost.localdomain> <1115664152.3032.28.camel@localhost.localdomain> <1115665781.4231.16.camel@daxter.boston.redhat.com> Message-ID: <1115666078.3032.31.camel@localhost.localdomain> On Mon, 2005-05-09 at 15:09 -0400, David Zeuthen wrote: > On Mon, 2005-05-09 at 19:42 +0100, Richard Hughes wrote: > > On Mon, 2005-05-09 at 17:28 +0100, Richard Hughes wrote: > > > > > I'll work on a patch. > > > > Attached, I know it's quick and dirty, but I wanted comments. > > Propose to make a generic function in hald/util.c and use it for both > APM, PMU and ACPI. No can do, for two reasons (unless I'm wrong:-): * APM / PMU / UPS already provide hardware-generated remaining_time values * APM / PMU do not provide charge/discharge rate values > > How > > expensive is setting an int as a property, then getting it? > > Only rule is to not set it multiple times as each time setting it will > emit a notification. That's what I thought. Thanks, Richard. _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Mon May 9 12:55:16 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:24 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115666078.3032.31.camel@localhost.localdomain> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> <1115656074.3032.3.camel@localhost.localdomain> <1115664152.3032.28.camel@localhost.localdomain> <1115665781.4231.16.camel@daxter.boston.redhat.com> <1115666078.3032.31.camel@localhost.localdomain> Message-ID: <1115668516.4231.20.camel@daxter.boston.redhat.com> On Mon, 2005-05-09 at 20:14 +0100, Richard Hughes wrote: > > Propose to make a generic function in hald/util.c and use it for both > > APM, PMU and ACPI. > > No can do, for two reasons (unless I'm wrong:-): > > * APM / PMU / UPS already provide hardware-generated remaining_time > values I think that would be driver-generated values. > * APM / PMU do not provide charge/discharge rate values PMU does. Anyway, it's good practice to solve the problem in a generic way even though only ACPI is using it. David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Mon May 9 13:35:21 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:24 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115668516.4231.20.camel@daxter.boston.redhat.com> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> <1115656074.3032.3.camel@localhost.localdomain> <1115664152.3032.28.camel@localhost.localdomain> <1115665781.4231.16.camel@daxter.boston.redhat.com> <1115666078.3032.31.camel@localhost.localdomain> <1115668516.4231.20.camel@daxter.boston.redhat.com> Message-ID: <1115670921.3032.38.camel@localhost.localdomain> On Mon, 2005-05-09 at 15:55 -0400, David Zeuthen wrote: > Anyway, it's good practice to solve the problem in a generic way even > though only ACPI is using it. Point taken. You mean create a function of the form: void setTimeRemaining (HalDevice *d) { gboolean isCharging, isDischarging; int chargeRate, chargeLevel, secondsRemaining, chargeLastFull; {hal_device_property_get_xxx} {do logic} {set "battery.remaining_time"} } and just call setTimeRemaining with the HalDevice? OR for a function to return the remaining time in seconds as an int and then to set battery.remaining_time with the return value? Thanks David. Richard. _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From yez at home.nl Mon May 9 16:24:42 2005 From: yez at home.nl (Edwin Schepers) Date: Mon Aug 15 18:49:24 2005 Subject: libhal_volume_get_mount_point not returning mountpoint Message-ID: <200505092324.42428.yez@home.nl> Hi, It seems that for my usb mass storage device, I don get a mountpoint on calling libhal_volume_get_mount_point. However, my fstab does contain the mountpoint ( /media/usbdisk ). Is this correct behaviour or is something wrong ? Regards, Edwin. _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From sf1183 at messiah.edu Mon May 9 21:27:59 2005 From: sf1183 at messiah.edu (Stephen Frank) Date: Mon Aug 15 18:49:24 2005 Subject: Appending options for partitioned disks Message-ID: As I was trying to get my usb thumbdrive to automount and unmount correctly under HAL and Ivman, I discovered that the default options that HAL uses to mount devices do not allow for non-root users to unmount them. In other words, you can't use the Linux equivalent of "safely remove hardware" if you are non-root. All that needs to happen to change this is to append "users" to the mount options when HAL creates the dynamic entry in fstab. Currently, the only way to make HAL do this by default (that I can find) is to set the key: storage.policy.default.mount_option.users to true But what if I don't want to set it to true by default, but only for thumbdrives? Well, I tried using a set of match tags to narrow my selection to only USB storage devices, then settings the key: storage.policy.mount_option.users to true but unfortunately, that key only applies when the device is non-partitioned. Thus, I cannot custom adjust the mounting options for partitioned disks. In the future, I would recommend that the storage.policy.default.mount_option.* be a key that can be used for any sort of disk, partitioned or not. I think this would aid developers in writing rulesets for their distributions - stuff like "remove hardware safely" scripts that worked for non-root users. What do you think? Steve _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From rohan.pm at gmail.com Tue May 10 03:40:25 2005 From: rohan.pm at gmail.com (Rohan McGovern) Date: Mon Aug 15 18:49:24 2005 Subject: [patch] libhal documentation Message-ID: <200505102040.25790.rohan.pm@gmail.com> Hi David, all... I decided guessing what the libhal functions do isn't so much fun anymore :-) So I filled in most of the blanks in libhal.h and libhal.c, and fixed some inconsistencies. All but two of the functions in libhal.h now have documentation, making libhal considerably easier to use (I think). The patch is far too big to submit here, so it's available at the following address: http://everest.fit.qut.edu.au/~n4722418/hal_cvs_doc.patch.gz Thank you, Rohan _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From arvidjaar at mail.ru Tue May 10 04:07:45 2005 From: arvidjaar at mail.ru (Andrey Borzenkov) Date: Mon Aug 15 18:49:24 2005 Subject: Appending options for partitioned disks In-Reply-To: References: Message-ID: <200505101507.58050.arvidjaar@mail.ru> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Tue May 10 07:24:03 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:24 2005 Subject: libhal_volume_get_mount_point not returning mountpoint In-Reply-To: <200505092324.42428.yez@home.nl> References: <200505092324.42428.yez@home.nl> Message-ID: <1115735043.4970.1.camel@daxter.boston.redhat.com> On Mon, 2005-05-09 at 23:24 +0000, Edwin Schepers wrote: > Hi, > It seems that for my usb mass storage device, I don get a mountpoint on > calling libhal_volume_get_mount_point. However, my fstab does contain the > mountpoint ( /media/usbdisk ). Is this correct behaviour or is something > wrong ? The said function will only return the location if the volume is actually mounted. Note that an /etc/fstab entry is not sufficient - someone may mount the volume in another location. Hope this helps, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From sf1183 at messiah.edu Tue May 10 08:30:53 2005 From: sf1183 at messiah.edu (Stephen Frank) Date: Mon Aug 15 18:49:24 2005 Subject: Appending options for partitioned disks Message-ID: >>> Andrey Borzenkov 05/10/05 7:07 AM >>> On Tuesday 10 May 2005 08:27, Stephen Frank wrote: [...] > But what if I don't want to set it to true by default, but only for > thumbdrives? Well, I tried using a set of match tags to narrow my selection > to only USB storage devices, then settings the key: > storage.policy.mount_option.users to true > but unfortunately, that key only applies when the device is > non-partitioned. Thus, I cannot custom adjust the mounting options for > partitioned disks. > do you mean that volume.policy.mount_option.* no more morks? {pts/1}% lshal | grep mount_opt lshal version 0.4.7 storage.policy.mount_option.iocharset=utf8 = true (bool) storage.policy.mount_option.codepage=866 = true (bool) volume.policy.mount_option.utf8 = true (bool) volume.policy.mount_option.iocharset=utf8 = true (bool) [...] -andrey Hmm. Yes, I had seen those, but I was under the impression that I could only apply them to very specific disks. I tried setting volume.policy.mount_option.*, but it didn't seem to carry through to subsets of devices. In other works, using hal-device-manager I could see that it successfully set those options for anything with the match characteristics I specficied (eg. the thing labelled STORAGE DEVICE), but the volume mounted under the STORAGE DEVICE did not retain those options becaue it did not match storage.bus=usb or info.category=storage. Here are the lines from my config.fdi file: true For those whos browsers tag-i-fied the XML up there, here is the same thing with the < replaced by (: (device) (!-- Match USB Storage Devices --) (match key="info.category" string="storage"> (match key="storage.bus" string="usb") (merge key="volume.policy.mount_option.users" type="bool")true(/merge) (/match) (/match) (/device) Here are parts of the output from lshal: udi = '/org/freedesktop/Hal/devices/block_50E0-D8B5' volume.mount_point = '' (string) volume.policy.mount_option.noatime = true (bool) volume.policy.mount_option.sync = true (bool) volume.policy.desired_mount_point = 'WOZARK' (string) volume.policy.mount_filesystem = 'vfat' (string) volume.policy.should_mount = true (bool) info.udi = '/org/freedesktop/Hal/devices/block_50E0-D8B5' (string) volume.partition.msdos_part_table_type = 11 (0xb) (int) volume.size = 262127616 (0xf9fc000) (uint64) volume.block_size = 512 (0x200) (int) volume.num_blocks = 511968 (0x7cfe0) (int) volume.partition.number = 1 (0x1) (int) volume.is_partition = true (bool) volume.is_mounted = false (bool) volume.is_disc = false (bool) volume.uuid = '50E0-D8B5' (string) volume.label = 'WOZARK' (string) volume.fsversion = 'FAT32' (string) volume.fsusage = 'filesystem' (string) volume.fstype = 'vfat' (string) info.product = 'WOZARK' (string) block.storage_device = '/org/freedesktop/Hal/devices/block_8_0' (string) block.minor = 1 (0x1) (int) block.major = 8 (0x8) (int) info.capabilities = 'block volume' (string) info.category = 'volume' (string) info.parent = '/org/freedesktop/Hal/devices/block_8_0' (string) block.device = '/dev/sda1' (string) block.is_volume = true (bool) block.have_scanned = false (bool) block.no_partitions = false (bool) linux.sysfs_path_device = '/sys/block/sda/sda1' (string) linux.sysfs_path = '/sys/block/sda/sda1' (string) info.bus = 'block' (string) udi = '/org/freedesktop/Hal/devices/block_8_0' volume.policy.mount_option.users = true (bool) storage.policy.should_mount = true (bool) info.udi = '/org/freedesktop/Hal/devices/block_8_0' (string) storage.requires_eject = false (bool) storage.hotpluggable = true (bool) storage.removable = true (bool) info.product = 'STORAGE DEVICE' (string) info.vendor = 'Generic' (string) storage.drive_type = 'disk' (string) block.storage_device = '/org/freedesktop/Hal/devices/block_8_0' (string) storage.physical_device = '/org/freedesktop/Hal/devices/usb_usb_device_781_8185_125_-1_000197113_0' (string) storage.vendor = 'Generic' (string) storage.model = 'STORAGE DEVICE' (string) storage.automount_enabled_hint = true (bool) storage.no_partitions_hint = false (bool) storage.media_check_enabled = true (bool) storage.bus = 'usb' (string) block.minor = 0 (0x0) (int) block.major = 8 (0x8) (int) info.capabilities = 'block storage' (string) info.category = 'storage' (string) block.device = '/dev/sda' (string) info.parent = '/org/freedesktop/Hal/devices/scsi_30_0_0_0' (string) block.is_volume = false (bool) block.have_scanned = false (bool) block.no_partitions = false (bool) linux.sysfs_path_device = '/sys/block/sda' (string) linux.sysfs_path = '/sys/block/sda' (string) info.bus = 'block' (string) As you can see, I would like to assign the mount option users to any USB storage device, not just to this one, so I use match to get USB storage devices. However, the result of this is that volume.policy.mount_option.users gets set to true for the parent device (my USB storage device), but this option never gets set on the child device (the mounted drive). This makes sense to me, since volume.policy.mount_option.* sounds like something that would apply only to a specific volume. I, however, want to assign a mount option oolicy to all matching storage devices, hence why I wanted to use storage.policy.mount_option.*. (Because in the end it's not practical to write a match for every single volume ever mounted. It seems like these volumes have no keys that that make them uniquely USB volumes, so it's difficult to write a generic rule for them. It would just get propagated to all volumes, USB or not, which isn't what I want.) _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From arvidjaar at mail.ru Tue May 10 09:10:26 2005 From: arvidjaar at mail.ru (Andrey Borzenkov) Date: Mon Aug 15 18:49:24 2005 Subject: Appending options for partitioned disks In-Reply-To: References: Message-ID: <200505102010.39530.arvidjaar@mail.ru> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From arvidjaar at mail.ru Tue May 10 09:12:43 2005 From: arvidjaar at mail.ru (Andrey Borzenkov) Date: Mon Aug 15 18:49:24 2005 Subject: Appending options for partitioned disks In-Reply-To: <200505102010.39530.arvidjaar@mail.ru> References: <200505102010.39530.arvidjaar@mail.ru> Message-ID: <200505102012.44314.arvidjaar@mail.ru> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Tue May 10 11:15:29 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:24 2005 Subject: [patch] libhal documentation In-Reply-To: <200505102040.25790.rohan.pm@gmail.com> References: <200505102040.25790.rohan.pm@gmail.com> Message-ID: <1115748929.4970.11.camel@daxter.boston.redhat.com> Hi, On Tue, 2005-05-10 at 20:40 +1000, Rohan McGovern wrote: > Hi David, all... > > I decided guessing what the libhal functions do isn't so much fun anymore :-) > So I filled in most of the blanks in libhal.h and libhal.c, and fixed some > inconsistencies. All but two of the functions in libhal.h now have > documentation, making libhal considerably easier to use (I think). > > The patch is far too big to submit here, so it's available at the following > address: http://everest.fit.qut.edu.au/~n4722418/hal_cvs_doc.patch.gz I see that you added the Doxygen comments to the libhal.h file and there are some duplicates (e.g. libhal_ctx_shutdown has comments in both libhal.h and libhal.c). I think it would be nice to only have these in one place (I think, traditionally, one uses the C file as far as it's possible). Any chance you can clear this up? Anyway, thanks a lot for the patch, I really appreciate it. Thanks, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Tue May 10 11:27:43 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115670921.3032.38.camel@localhost.localdomain> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> <1115656074.3032.3.camel@localhost.localdomain> <1115664152.3032.28.camel@localhost.localdomain> <1115665781.4231.16.camel@daxter.boston.redhat.com> <1115666078.3032.31.camel@localhost.localdomain> <1115668516.4231.20.camel@daxter.boston.redhat.com> <1115670921.3032.38.camel@localhost.localdomain> Message-ID: <1115749663.3007.3.camel@localhost.localdomain> On Mon, 2005-05-09 at 21:35 +0100, Richard Hughes wrote: > On Mon, 2005-05-09 at 15:55 -0400, David Zeuthen wrote: > > > Anyway, it's good practice to solve the problem in a generic way even > > though only ACPI is using it. > > Point taken. > You mean create a function of the form: > > void setTimeRemaining (HalDevice *d) > { > gboolean isCharging, isDischarging; > int chargeRate, chargeLevel, secondsRemaining, chargeLastFull; > > {hal_device_property_get_xxx} > {do logic} > {set "battery.remaining_time"} > } > > and just call setTimeRemaining with the HalDevice? > > OR for a function to return the remaining time in seconds as an int and > then to set battery.remaining_time with the return value? Another question, hal_device_property_set_int (d, "foo", 6); hal_device_property_set_int (d, "foo", 6); hal_device_property_set_int (d, "foo", 6); hal_device_property_set_int (d, "foo", 6); hal_device_property_set_int (d, "foo", 6); Will I get 5 lots of DBUS traffic, and if not there a big overhead anyway? My question is, do I need to check for (oldvalue!=newvalue) before using hal_device_property_set_int? Thanks. _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Tue May 10 11:35:55 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115749663.3007.3.camel@localhost.localdomain> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> <1115656074.3032.3.camel@localhost.localdomain> <1115664152.3032.28.camel@localhost.localdomain> <1115665781.4231.16.camel@daxter.boston.redhat.com> <1115666078.3032.31.camel@localhost.localdomain> <1115668516.4231.20.camel@daxter.boston.redhat.com> <1115670921.3032.38.camel@localhost.localdomain> <1115749663.3007.3.camel@localhost.localdomain> Message-ID: <1115750155.4970.19.camel@daxter.boston.redhat.com> On Tue, 2005-05-10 at 19:27 +0100, Richard Hughes wrote: > On Mon, 2005-05-09 at 21:35 +0100, Richard Hughes wrote: > > On Mon, 2005-05-09 at 15:55 -0400, David Zeuthen wrote: > > > > > Anyway, it's good practice to solve the problem in a generic way even > > > though only ACPI is using it. > > > > Point taken. > > You mean create a function of the form: > > > > void setTimeRemaining (HalDevice *d) > > { > > gboolean isCharging, isDischarging; > > int chargeRate, chargeLevel, secondsRemaining, chargeLastFull; > > > > {hal_device_property_get_xxx} > > {do logic} > > {set "battery.remaining_time"} > > } > > > > and just call setTimeRemaining with the HalDevice? > > > > OR for a function to return the remaining time in seconds as an int and > > then to set battery.remaining_time with the return value? Oh, sorry, I missed this one. I would just create a function double util_compute_time_remaining (const char *id, double curRate, double curLevel, bool is_charging); then we can always swap in another function that may do more interesting stuff in the future. > Another question, > > hal_device_property_set_int (d, "foo", 6); > hal_device_property_set_int (d, "foo", 6); > hal_device_property_set_int (d, "foo", 6); > hal_device_property_set_int (d, "foo", 6); > hal_device_property_set_int (d, "foo", 6); > > Will I get 5 lots of DBUS traffic, and if not there a big overhead > anyway? One way is to try it together with lshal --monitor :-). The answer is that we hal_device_property_set_* refuses to send a notification if nothing changes. > My question is, do I need to check for (oldvalue!=newvalue) before using > hal_device_property_set_int? Nope. Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Tue May 10 12:01:20 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115750155.4970.19.camel@daxter.boston.redhat.com> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> <1115656074.3032.3.camel@localhost.localdomain> <1115664152.3032.28.camel@localhost.localdomain> <1115665781.4231.16.camel@daxter.boston.redhat.com> <1115666078.3032.31.camel@localhost.localdomain> <1115668516.4231.20.camel@daxter.boston.redhat.com> <1115670921.3032.38.camel@localhost.localdomain> <1115749663.3007.3.camel@localhost.localdomain> <1115750155.4970.19.camel@daxter.boston.redhat.com> Message-ID: <1115751681.3007.10.camel@localhost.localdomain> On Tue, 2005-05-10 at 14:35 -0400, David Zeuthen wrote: > Oh, sorry, I missed this one. I would just create a function > > double util_compute_time_remaining (const char *id, > double curRate, > double curLevel, > bool is_charging); > > then we can always swap in another function that may do more interesting > stuff in the future. Can I disagree? We need more variables than that: double util_compute_time_remaining (const char *id, double curRate, double curLevel, double curLevelLastFull, bool is_discharging, bool is_charging); Which makes a bit of a wieldy prototype (and means we have to look up all the values even if we don't use them in the calculation.) I was thinking of something minimal like this: static void battery_calculate_minutes (HalDevice *d) { int chargeRate, chargeLevel, chargeLastFull; int secondsRemaining; /* work out minutesRemaining as value is not provided by ACPI */ chargeRate = hal_device_property_get_int (d, "battery.charge_level.rate"); if (chargeRate =< 0) return; if (hal_device_property_get_bool (d, "battery.rechargeable.is_discharging")) { chargeLevel = hal_device_property_get_int (d, "battery.charge_level.current"); secondsRemaining = ((double) chargeLevel / (double) chargeRate) * 60 * 60; hal_device_property_set_int (d, "battery.remaining_time", secondsRemaining); return; } if (hal_device_property_get_bool (d, "battery.rechargeable.is_charging")) { chargeLevel = hal_device_property_get_int (d, "battery.charge_level.current"); chargeLastFull = hal_device_property_get_int (d, "battery.charge_level.last_full"); secondsRemaining = ((double) (chargeLastFull - chargeLevel) / (double) chargeRate) * 60 * 60; hal_device_property_set_int (d, "battery.remaining_time", secondsRemaining); return; } } Which only does the needed lookups and could easily be replaced in the future with a different algorithm. Is this the sort of thing you mean? > > > Another question, > > > > hal_device_property_set_int (d, "foo", 6); > > > > Will I get 5 lots of DBUS traffic, and if not there a big overhead > > anyway? > > One way is to try it together with lshal --monitor :-). Bugger. :-) > The answer is > that we hal_device_property_set_* refuses to send a notification if > nothing changes. That's what I thought. Goodie good. Richard. _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Tue May 10 12:14:25 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115751681.3007.10.camel@localhost.localdomain> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> <1115656074.3032.3.camel@localhost.localdomain> <1115664152.3032.28.camel@localhost.localdomain> <1115665781.4231.16.camel@daxter.boston.redhat.com> <1115666078.3032.31.camel@localhost.localdomain> <1115668516.4231.20.camel@daxter.boston.redhat.com> <1115670921.3032.38.camel@localhost.localdomain> <1115749663.3007.3.camel@localhost.localdomain> <1115750155.4970.19.camel@daxter.boston.redhat.com> <1115751681.3007.10.camel@localhost.localdomain> Message-ID: <1115752466.4970.32.camel@daxter.boston.redhat.com> On Tue, 2005-05-10 at 20:01 +0100, Richard Hughes wrote: > On Tue, 2005-05-10 at 14:35 -0400, David Zeuthen wrote: > > Oh, sorry, I missed this one. I would just create a function > > > > double util_compute_time_remaining (const char *id, > > double curRate, > > double curLevel, > > bool is_charging); > > > > then we can always swap in another function that may do more interesting > > stuff in the future. > > Can I disagree? We need more variables than that: > > double util_compute_time_remaining (const char *id, > double curRate, > double curLevel, > double curLevelLastFull, > bool is_discharging, > bool is_charging); > > Which makes a bit of a wieldy prototype (and means we have to > look up all the values even if we don't use them in the calculation.) Which is not really a big deal. This only gets called on the order of once every 30th second per battery so... > I was thinking of something minimal like this: > > static void > battery_calculate_minutes (HalDevice *d) I don't really like this; it makes it more difficult to drop in another implementation without having to know what a HalDevice* is... Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Tue May 10 12:56:01 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115752466.4970.32.camel@daxter.boston.redhat.com> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> <1115656074.3032.3.camel@localhost.localdomain> <1115664152.3032.28.camel@localhost.localdomain> <1115665781.4231.16.camel@daxter.boston.redhat.com> <1115666078.3032.31.camel@localhost.localdomain> <1115668516.4231.20.camel@daxter.boston.redhat.com> <1115670921.3032.38.camel@localhost.localdomain> <1115749663.3007.3.camel@localhost.localdomain> <1115750155.4970.19.camel@daxter.boston.redhat.com> <1115751681.3007.10.camel@localhost.localdomain> <1115752466.4970.32.camel@daxter.boston.redhat.com> Message-ID: <1115754961.3007.13.camel@localhost.localdomain> On Tue, 2005-05-10 at 15:14 -0400, David Zeuthen wrote: > On Tue, 2005-05-10 at 20:01 +0100, Richard Hughes wrote: > > On Tue, 2005-05-10 at 14:35 -0400, David Zeuthen wrote: > > > Oh, sorry, I missed this one. I would just create a function > > > > > > double util_compute_time_remaining (const char *id, > > > double curRate, > > > double curLevel, > > > bool is_charging); > > > > > > then we can always swap in another function that may do more interesting > > > stuff in the future. > > > > Can I disagree? We need more variables than that: > > > > double util_compute_time_remaining (const char *id, > > double curRate, > > double curLevel, > > double curLevelLastFull, > > bool is_discharging, > > bool is_charging); > > > > Which makes a bit of a wieldy prototype (and means we have to > > look up all the values even if we don't use them in the calculation.) > > Which is not really a big deal. This only gets called on the order of > once every 30th second per battery so... Okay, I'll run with you with this. Why return a double? int is good enough for seconds... Also, whats the *id for? > I don't really like this; it makes it more difficult to drop in another > implementation without having to know what a HalDevice* is... Working on a patch now. R. _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Tue May 10 12:58:58 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115754961.3007.13.camel@localhost.localdomain> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> <1115656074.3032.3.camel@localhost.localdomain> <1115664152.3032.28.camel@localhost.localdomain> <1115665781.4231.16.camel@daxter.boston.redhat.com> <1115666078.3032.31.camel@localhost.localdomain> <1115668516.4231.20.camel@daxter.boston.redhat.com> <1115670921.3032.38.camel@localhost.localdomain> <1115749663.3007.3.camel@localhost.localdomain> <1115750155.4970.19.camel@daxter.boston.redhat.com> <1115751681.3007.10.camel@localhost.localdomain> <1115752466.4970.32.camel@daxter.boston.redhat.com> <1115754961.3007.13.camel@localhost.localdomain> Message-ID: <1115755138.4970.34.camel@daxter.boston.redhat.com> On Tue, 2005-05-10 at 20:56 +0100, Richard Hughes wrote: > > Which is not really a big deal. This only gets called on the order of > > once every 30th second per battery so... > > Okay, I'll run with you with this. > > Why return a double? int is good enough for seconds... I suppose we could return an int instead :-) - I'm just dishing out code on the mailing list, go easy on me :-) > Also, whats the > *id for? Suppose my implementation wants to store history then I need something unique to store it under (since this function will possibly get called for several batteries).. > > > I don't really like this; it makes it more difficult to drop in another > > implementation without having to know what a HalDevice* is... > > Working on a patch now. Great! Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Tue May 10 13:22:10 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115755138.4970.34.camel@daxter.boston.redhat.com> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> <1115656074.3032.3.camel@localhost.localdomain> <1115664152.3032.28.camel@localhost.localdomain> <1115665781.4231.16.camel@daxter.boston.redhat.com> <1115666078.3032.31.camel@localhost.localdomain> <1115668516.4231.20.camel@daxter.boston.redhat.com> <1115670921.3032.38.camel@localhost.localdomain> <1115749663.3007.3.camel@localhost.localdomain> <1115750155.4970.19.camel@daxter.boston.redhat.com> <1115751681.3007.10.camel@localhost.localdomain> <1115752466.4970.32.camel@daxter.boston.redhat.com> <1115754961.3007.13.camel@localhost.localdomain> <1115755138.4970.34.camel@daxter.boston.redhat.com> Message-ID: <1115756530.3007.17.camel@localhost.localdomain> On Tue, 2005-05-10 at 15:58 -0400, David Zeuthen wrote: > I suppose we could return an int instead :-) - I'm just dishing out code > on the mailing list, go easy on me :-) Sorry :-) > > Also, whats the > > *id for? > > Suppose my implementation wants to store history then I need something > unique to store it under (since this function will possibly get called > for several batteries).. Good plan. > > > > > I don't really like this; it makes it more difficult to drop in another > > > implementation without having to know what a HalDevice* is... > > > > Working on a patch now. Attached, feel free to mangle/rename/abuse. Thanks, Richard. -------------- next part -------------- A non-text attachment was scrubbed... Name: hal-add-time-02.patch Type: text/x-patch Size: 4594 bytes Desc: not available Url : http://lists.freedesktop.org/archives/hal/attachments/20050510/0a5db91d/hal-add-time-02.bin -------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Tue May 10 13:54:07 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] addon-usb-csr.c : make screen scroll less by cutting out the blank lines Message-ID: <1115758447.3007.24.camel@localhost.localdomain> When running hald verbose, I get the following in the console: 11092: 21:46:27.145: addon-usb-csr.c:223: Is dual: 0 11092: 21:46:27.145: addon-usb-csr.c:287: Looking for: [002][005] 11092: 21:46:27.145: addon-usb-csr.c:309: Matched device: [002][005][046D:C50E] i.e. a blank line in between each dbg function caused by the trailing "\n" that is present. I've attached a trivial patch which makes the screen scrolling more manageable. Please merge if acceptable. Thanks, Richard. -------------- next part -------------- A non-text attachment was scrubbed... Name: csr-extra-line.patch Type: text/x-patch Size: 4451 bytes Desc: not available Url : http://lists.freedesktop.org/archives/hal/attachments/20050510/314be789/csr-extra-line.bin -------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From rohan.pm at gmail.com Tue May 10 16:35:47 2005 From: rohan.pm at gmail.com (Rohan McGovern) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] libhal documentation In-Reply-To: <1115748929.4970.11.camel@daxter.boston.redhat.com> References: <200505102040.25790.rohan.pm@gmail.com> <1115748929.4970.11.camel@daxter.boston.redhat.com> Message-ID: <200505110935.47606.rohan.pm@gmail.com> On Wed, 11 May 2005 04:15, David Zeuthen wrote: > ... > I see that you added the Doxygen comments to the libhal.h file and there > are some duplicates (e.g. libhal_ctx_shutdown has comments in both > libhal.h and libhal.c). I think it would be nice to only have these in > one place (I think, traditionally, one uses the C file as far as it's > possible). Any chance you can clear this up? > OK, the .h file now has only brief comments, while the .c file has the full documentation, I hope this is acceptable :-) I have usually used the .h file for doxygen comments, since sometimes the .h file is all users have, and I still couldn't bring myself to remove the comments from .h entirely, but I think it should be OK now; the brief comments in libhal.h aren't likely to ever need to change, so there's only one copy of documentation to maintain. Patch is, once again, available at http://everest.fit.qut.edu.au/~n4722418/hal_cvs_doc.patch.gz :-) -- Rohan McGovern _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From yez at home.nl Wed May 11 07:35:21 2005 From: yez at home.nl (Edwin Schepers) Date: Mon Aug 15 18:49:25 2005 Subject: unknown property camera.access_method Message-ID: <200505111435.22378.yez@home.nl> Hi, Is the method camera.access_method new in HAL 0.5.1 ? It seems to be mandatory but is not present with my camera on HAL 0.5.0 My actual problem is that my camera is not recognized. The software is doing a libhal_device_query_capability(m_halContext, udi, "camera", NULL) and this function returns False. However, if I use gtkam or digikam, the device is accessible with no problem. Now I'm searching for a way to get the camera recognized. "info.capabilities" also seem not to be present. Do you have a solution? Thanks, Edwin _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From johnp at redhat.com Wed May 11 07:06:08 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] libhal documentation In-Reply-To: <200505110935.47606.rohan.pm@gmail.com> References: <200505102040.25790.rohan.pm@gmail.com> <1115748929.4970.11.camel@daxter.boston.redhat.com> <200505110935.47606.rohan.pm@gmail.com> Message-ID: <1115820368.4627.6.camel@localhost.localdomain> On Tue, 2005-05-10 at 19:35, Rohan McGovern wrote: > On Wed, 11 May 2005 04:15, David Zeuthen wrote: > > ... > > I see that you added the Doxygen comments to the libhal.h file and there > > are some duplicates (e.g. libhal_ctx_shutdown has comments in both > > libhal.h and libhal.c). I think it would be nice to only have these in > > one place (I think, traditionally, one uses the C file as far as it's > > possible). Any chance you can clear this up? > > > > OK, the .h file now has only brief comments, while the .c file has the full > documentation, I hope this is acceptable :-) I have usually used the .h file > for doxygen comments, since sometimes the .h file is all users have, and I > still couldn't bring myself to remove the comments from .h entirely, but I > think it should be OK now; the brief comments in libhal.h aren't likely to > ever need to change, so there's only one copy of documentation to maintain. > > Patch is, once again, available at > http://everest.fit.qut.edu.au/~n4722418/hal_cvs_doc.patch.gz :-) Ya, I never really understood why we do the documentation in the C files (isn't the header files just documentation of the interfaces anyway?), but the convention is to have the header files as sparse as possible and put all verbosity in the c files. -- J5 _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Wed May 11 10:21:19 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] libhal documentation In-Reply-To: <200505110935.47606.rohan.pm@gmail.com> References: <200505102040.25790.rohan.pm@gmail.com> <1115748929.4970.11.camel@daxter.boston.redhat.com> <200505110935.47606.rohan.pm@gmail.com> Message-ID: <1115832079.4250.7.camel@daxter.boston.redhat.com> On Wed, 2005-05-11 at 09:35 +1000, Rohan McGovern wrote: > On Wed, 11 May 2005 04:15, David Zeuthen wrote: > > ... > > I see that you added the Doxygen comments to the libhal.h file and there > > are some duplicates (e.g. libhal_ctx_shutdown has comments in both > > libhal.h and libhal.c). I think it would be nice to only have these in > > one place (I think, traditionally, one uses the C file as far as it's > > possible). Any chance you can clear this up? > > > > OK, the .h file now has only brief comments, while the .c file has the full > documentation, I hope this is acceptable :-) I have usually used the .h file > for doxygen comments, since sometimes the .h file is all users have, and I > still couldn't bring myself to remove the comments from .h entirely, but I > think it should be OK now; the brief comments in libhal.h aren't likely to > ever need to change, so there's only one copy of documentation to maintain. > > Patch is, once again, available at > http://everest.fit.qut.edu.au/~n4722418/hal_cvs_doc.patch.gz :-) Very nice, I've committed this! Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Wed May 11 10:48:47 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115756530.3007.17.camel@localhost.localdomain> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> <1115656074.3032.3.camel@localhost.localdomain> <1115664152.3032.28.camel@localhost.localdomain> <1115665781.4231.16.camel@daxter.boston.redhat.com> <1115666078.3032.31.camel@localhost.localdomain> <1115668516.4231.20.camel@daxter.boston.redhat.com> <1115670921.3032.38.camel@localhost.localdomain> <1115749663.3007.3.camel@localhost.localdomain> <1115750155.4970.19.camel@daxter.boston.redhat.com> <1115751681.3007.10.camel@localhost.localdomain> <1115752466.4970.32.camel@daxter.boston.redhat.com> <1115754961.3007.13.camel@localhost.localdomain> <1115755138.4970.34.camel@daxter.boston.redhat.com> <1115756530.3007.17.camel@localhost.localdomain> Message-ID: <1115833728.4250.9.camel@daxter.boston.redhat.com> On Tue, 2005-05-10 at 21:22 +0100, Richard Hughes wrote: > Attached, feel free to mangle/rename/abuse. I've committed something like this. Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Wed May 11 10:49:19 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] addon-usb-csr.c : make screen scroll less by cutting out the blank lines In-Reply-To: <1115758447.3007.24.camel@localhost.localdomain> References: <1115758447.3007.24.camel@localhost.localdomain> Message-ID: <1115833759.4250.11.camel@daxter.boston.redhat.com> On Tue, 2005-05-10 at 21:54 +0100, Richard Hughes wrote: > Please merge if acceptable. I think that this is now fixed. Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Wed May 11 11:21:37 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115833728.4250.9.camel@daxter.boston.redhat.com> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> <1115656074.3032.3.camel@localhost.localdomain> <1115664152.3032.28.camel@localhost.localdomain> <1115665781.4231.16.camel@daxter.boston.redhat.com> <1115666078.3032.31.camel@localhost.localdomain> <1115668516.4231.20.camel@daxter.boston.redhat.com> <1115670921.3032.38.camel@localhost.localdomain> <1115749663.3007.3.camel@localhost.localdomain> <1115750155.4970.19.camel@daxter.boston.redhat.com> <1115751681.3007.10.camel@localhost.localdomain> <1115752466.4970.32.camel@daxter.boston.redhat.com> <1115754961.3007.13.camel@localhost.localdomain> <1115755138.4970.34.camel@daxter.boston.redhat.com> <1115756530.3007.17.camel@localhost.localdomain> <1115833728.4250.9.camel@daxter.boston.redhat.com> Message-ID: <1115835697.2961.8.camel@localhost.localdomain> On Wed, 2005-05-11 at 13:48 -0400, David Zeuthen wrote: > On Tue, 2005-05-10 at 21:22 +0100, Richard Hughes wrote: > > Attached, feel free to mangle/rename/abuse. > > I've committed something like this. Brilliant. I've just removed 62 - YES 62 lines of special case ACPI handling in GNOME Power Manager. Makes life somewhat easier. :-) Richard. _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Wed May 11 11:26:17 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115835697.2961.8.camel@localhost.localdomain> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> <1115656074.3032.3.camel@localhost.localdomain> <1115664152.3032.28.camel@localhost.localdomain> <1115665781.4231.16.camel@daxter.boston.redhat.com> <1115666078.3032.31.camel@localhost.localdomain> <1115668516.4231.20.camel@daxter.boston.redhat.com> <1115670921.3032.38.camel@localhost.localdomain> <1115749663.3007.3.camel@localhost.localdomain> <1115750155.4970.19.camel@daxter.boston.redhat.com> <1115751681.3007.10.camel@localhost.localdomain> <1115752466.4970.32.camel@daxter.boston.redhat.com> <1115754961.3007.13.camel@localhost.localdomain> <1115755138.4970.34.camel@daxter.boston.redhat.com> <1115756530.3007.17.camel@localhost.localdomain> <1115833728.4250.9.camel@daxter.boston.redhat.com> <1115835697.2961.8.camel@localhost.localdomain> Message-ID: <1115835977.4250.23.camel@daxter.boston.redhat.com> On Wed, 2005-05-11 at 19:21 +0100, Richard Hughes wrote: > On Wed, 2005-05-11 at 13:48 -0400, David Zeuthen wrote: > > On Tue, 2005-05-10 at 21:22 +0100, Richard Hughes wrote: > > > Attached, feel free to mangle/rename/abuse. > > > > I've committed something like this. > > Brilliant. I've just removed 62 - YES 62 lines of special case ACPI > handling in GNOME Power Manager. > > Makes life somewhat easier. Cool, what about a patch to hal to do this for APM too? :-) Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Wed May 11 11:40:03 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115835977.4250.23.camel@daxter.boston.redhat.com> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> <1115656074.3032.3.camel@localhost.localdomain> <1115664152.3032.28.camel@localhost.localdomain> <1115665781.4231.16.camel@daxter.boston.redhat.com> <1115666078.3032.31.camel@localhost.localdomain> <1115668516.4231.20.camel@daxter.boston.redhat.com> <1115670921.3032.38.camel@localhost.localdomain> <1115749663.3007.3.camel@localhost.localdomain> <1115750155.4970.19.camel@daxter.boston.redhat.com> <1115751681.3007.10.camel@localhost.localdomain> <1115752466.4970.32.camel@daxter.boston.redhat.com> <1115754961.3007.13.camel@localhost.localdomain> <1115755138.4970.34.camel@daxter.boston.redhat.com> <1115756530.3007.17.camel@localhost.localdomain> <1115833728.4250.9.camel@daxter.boston.redhat.com> <1115835697.2961.8.camel@localhost.localdomain> <1115835977.4250.23.camel@daxter.boston.redhat.com> Message-ID: <1115836803.2961.9.camel@localhost.localdomain> On Wed, 2005-05-11 at 14:26 -0400, David Zeuthen wrote: > Cool, what about a patch to hal to do this for APM too? :-) Talking of which, what became of the discussion to add polling to PMU and APM? I think I went on holiday when it all got interesting :-) R. _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Wed May 11 11:53:41 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115836803.2961.9.camel@localhost.localdomain> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> <1115656074.3032.3.camel@localhost.localdomain> <1115664152.3032.28.camel@localhost.localdomain> <1115665781.4231.16.camel@daxter.boston.redhat.com> <1115666078.3032.31.camel@localhost.localdomain> <1115668516.4231.20.camel@daxter.boston.redhat.com> <1115670921.3032.38.camel@localhost.localdomain> <1115749663.3007.3.camel@localhost.localdomain> <1115750155.4970.19.camel@daxter.boston.redhat.com> <1115751681.3007.10.camel@localhost.localdomain> <1115752466.4970.32.camel@daxter.boston.redhat.com> <1115754961.3007.13.camel@localhost.localdomain> <1115755138.4970.34.camel@daxter.boston.redhat.com> <1115756530.3007.17.camel@localhost.localdomain> <1115833728.4250.9.camel@daxter.boston.redhat.com> <1115835697.2961.8.camel@localhost.localdomain> <1115835977.4250.23.camel@daxter.boston.redhat.com> <1115836803.2961.9.camel@localhost.localdomain> Message-ID: <1115837622.4250.25.camel@daxter.boston.redhat.com> On Wed, 2005-05-11 at 19:40 +0100, Richard Hughes wrote: > On Wed, 2005-05-11 at 14:26 -0400, David Zeuthen wrote: > > Cool, what about a patch to hal to do this for APM too? :-) > > Talking of which, what became of the discussion to add polling to PMU > and APM? I think I went on holiday when it all got interesting :-) I fixed that in CVS a few days ago. Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Wed May 11 11:59:02 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] addon-hid-ups.c : battery.present is mandatory for HAL spec In-Reply-To: <1115837622.4250.25.camel@daxter.boston.redhat.com> References: <1115577151.3201.4.camel@localhost.localdomain> <427E73C3.7090100@drzeus.cx> <427E74AA.5080609@suwalski.net> <1115585601.3201.10.camel@localhost.localdomain> <1115611304.4833.12.camel@powerbook.fubar.dk> <1115620745.2984.12.camel@localhost.localdomain> <1115649484.4231.3.camel@daxter.boston.redhat.com> <1115649639.4231.5.camel@daxter.boston.redhat.com> <1115656074.3032.3.camel@localhost.localdomain> <1115664152.3032.28.camel@localhost.localdomain> <1115665781.4231.16.camel@daxter.boston.redhat.com> <1115666078.3032.31.camel@localhost.localdomain> <1115668516.4231.20.camel@daxter.boston.redhat.com> <1115670921.3032.38.camel@localhost.localdomain> <1115749663.3007.3.camel@localhost.localdomain> <1115750155.4970.19.camel@daxter.boston.redhat.com> <1115751681.3007.10.camel@localhost.localdomain> <1115752466.4970.32.camel@daxter.boston.redhat.com> <1115754961.3007.13.camel@localhost.localdomain> <1115755138.4970.34.camel@daxter.boston.redhat.com> <1115756530.3007.17.camel@localhost.localdomain> <1115833728.4250.9.camel@daxter.boston.redhat.com> <1115835697.2961.8.camel@localhost.localdomain> <1115835977.4250.23.camel@daxter.boston.redhat.com> <1115836803.2961.9.camel@localhost.localdomain> <1115837622.4250.25.camel@daxter.boston.redhat.com> Message-ID: <1115837942.4857.0.camel@localhost.localdomain> On Wed, 2005-05-11 at 14:53 -0400, David Zeuthen wrote: > On Wed, 2005-05-11 at 19:40 +0100, Richard Hughes wrote: > > On Wed, 2005-05-11 at 14:26 -0400, David Zeuthen wrote: > > > Cool, what about a patch to hal to do this for APM too? :-) > > > > Talking of which, what became of the discussion to add polling to PMU > > and APM? I think I went on holiday when it all got interesting :-) > > I fixed that in CVS a few days ago. Good man :-) _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From sf1183 at messiah.edu Wed May 11 12:51:57 2005 From: sf1183 at messiah.edu (Stephen Frank) Date: Mon Aug 15 18:49:25 2005 Subject: Appending options for partitioned disks Message-ID: >So set it for child device. > > > > type="bool">true > > > >-andrey Ah! I didn't think about that. I will try that. Thank you. steve _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Thu May 12 12:28:19 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: unknown property camera.access_method In-Reply-To: <200505111435.22378.yez@home.nl> References: <200505111435.22378.yez@home.nl> Message-ID: <1115926099.4248.22.camel@daxter.boston.redhat.com> On Wed, 2005-05-11 at 14:35 +0000, Edwin Schepers wrote: > Hi, > Is the method camera.access_method new in HAL 0.5.1 ? It seems to be mandatory > but is not present with my camera on HAL 0.5.0 > > My actual problem is that my camera is not recognized. The software is doing a > libhal_device_query_capability(m_halContext, udi, "camera", NULL) and this > function returns False. However, if I use gtkam or digikam, the device is > accessible with no problem. > Now I'm searching for a way to get the camera recognized. "info.capabilities" > also seem not to be present. > > Do you have a solution? > Yeah, the device information files for cameras doesn't ship with hal 0.5.1. I've added the PTP one to hal cvs (will be part of the 0.5.2 release) and I've also added Pozsar Balazs script to generate the device information file from libgphoto2 to the tools/ directory. I am working on a patch to submit to libgphoto2 such that the device information file is installed with the library (in Fedora Rawhide we ship patched version of libgphoto2 that does exactly this). Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Thu May 12 13:00:50 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: deprecating fstab-sync with mount wrapper (Was Re: Appending options for partitioned disk) In-Reply-To: References: Message-ID: <1115928050.4248.53.camel@daxter.boston.redhat.com> Hi, I think this thread http://lists.freedesktop.org/archives/hal/2005-May/002490.html and countless others, shows that using hal properties (storage.policy.* and volume.policy.*) to specify policy for mounting / unmounting volumes isn't really the way to go :-). Specific complaints of mine (most severe issues comes first) o it's too complicated o difficult to build a GUI for managing this o difficult to adjust per-user o there really needs to be a way for the mount program to interact with the desktop user (to e.g. bypass lockdown) [1]. It seemed like a good idea at the time we did this, but I think we can do better. Ideally, what I like is the following o Remove all storage.policy.* and volume.policy.* properties. It shouldn't be in hal o Move all policy into a ''policy mount wrapper'' a'la pmount, let's just call it hmount for the time being :-). I'm not attached to what it is called o hmount has a well defined programmatic interface (since we may have different implementations for KDE and GNOME) o hmount reads policy from gconf (on GNOME) or KConfig (on KDE) - this is mostly such that it's easy to lock down and it's easy to write UI to reconfigure policy. Here are some common things the UI should support - Specify mount point to use / mount options / whether to mount read only (for lock down). Use the HAL UDI as the unique key. Suggest to, for GNOME, integrate this UI upstream in Nautilus. - Specify whether the volume/drive should be visible to the user at all: (a) it may be too risky to show e.g. partitions on the fixed IDE drive since fs detection is a risky; (b) in the data center we don't want to show SCSI drives stemming from e.g Fibre Channel [2] o hmount should pop up a notification bubble / dialog if mounting read-only and ask if the user wants to authorize for mounting read-write. I've copied utopia-list@gnome.org and pmount developer Martin Pitt to hear whether he is interested in collaborating on this. I certainly think this is something worth fixing upstream. Cheers, David [1] : OK, so lock down is controversial. Suffice to say, some enterprise users wants this and I can imagine it's useful in libraries etc. Also see this article http://www.pbs.org/cringely/pulpit/pulpit20040916.html and search for epoxy. [2] : Actually, once I had a bug for a Red Hat Enterprise Linux 4 beta regarding more than 100 icons showing up on the GNOME desktop :-) _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Thu May 12 14:22:46 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: hal 0.5.2 "Can't do it, Sally." released Message-ID: <1115932966.4248.57.camel@daxter.boston.redhat.com> Hi, Here's a new release. Not really a lot of changes, just mainly bugfixes for now. Download from http://freedesktop.org/~david/dist/hal-0.5.2.tar.gz Changes from 0.5.1 - Calculate remaining time for batteries (Richard Hughes) - libhal documentation update (Rohan McGovern) - Tweak default policy to automount 'mmc' devices (Pierre Ossman) - PMU lid button and battery polling fixes (David Zeuthen) - Detect PTP cameras (Pozsar Balazs) - Include script to generate libgphoto2 .fdi file (Pozsar Balazs) - Unmount by mount point instead of by device file (Rohan McGovern) Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From rohan.pm at gmail.com Thu May 12 16:10:31 2005 From: rohan.pm at gmail.com (Rohan McGovern) Date: Mon Aug 15 18:49:25 2005 Subject: ACPI inconsistent button state Message-ID: <200505130910.32623.rohan.pm@gmail.com> Hi all, I've been using Ivman to hibernate my laptop, and an issue with HAL's ACPI support has come to light. Basically, when I close the lid of my laptop, it will hibernate; when I open the lid of my laptop and turn it back on, it will resume, and HAL will still think the lid is closed (presumably because it was opened while the power was off). Specifically, button.state.value = true on /org/freedesktop/Hal/devices/acpi_LID, when it should be false. Luckily this is trivial to work around (just have a hal-set-property command after the hibernate script), but a fix in the HAL source would be nice :-) The '/proc/acpi/button/lid/LID/state' file gives the correct state for the lid no matter what, so this is definitely fixable at HAL's level. It seems to me like this could be fixed by calling acpi_rescan_device (or button_refresh) on the lid device at some point, but from looking at the output of lshal --monitor while hibernating, there doesn't appear to be any obvious event which consistently occurs where it makes sense to do this. It could be done in acpi_poll, but hopefully someone with greater insight and knowledge of HAL can think of a more efficient way :-) This problem probably extends to all ACPI buttons with button.has_state = true . -- Rohan McGovern _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From richard.hughes4 at baesystems.com Fri May 13 02:01:14 2005 From: richard.hughes4 at baesystems.com (Hughes, Richard (UK Rochester)) Date: Mon Aug 15 18:49:25 2005 Subject: suspend2 checks Message-ID: I've been sent a patch by Ow Mun Heng (to the gnome-power mailing list) to add the check for suspend2 in acpi.c Is this something that belongs in HAL? I know that hal-spec.xml.in would need patching too, but included the patch as received for now. Thanks, Richard. Undergraduate Placement Student BAE SYSTEMS Operations Ltd. Avionic Systems Test Equipment P306 Airport Works, Rochester, Kent, ME1 2XX. +44 (0) 1634 205108 / +791 5618 richard.hughes4@baesystems.com -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.2.6 (GNU/Linux) mQGiBEGBLRIRBACFZQTypQa6FsLbc3JX8VIfNd3b4gOqj3fCALxIYIWgNnif3qau 9hbY0VUYIcsgwlD+b6CnR2tepZnMar1vDxjPRzi0Zf6531if7iAObVqE0uaa7gzQ diTC32uuxSLA8sG8Kqoy1Z9ckI/lu5SwNdLkvvGpqqeQcpEbeyBcixz8jwCggglo 8nWsUCw1XLLf0bYjUXI8HOkD/1bStATVY3tHNOV/+6N36wNRUM0wYbq3jNDbNPyL sc/L2x3k2rR+5oyGS7GIgkDSMZ7TGDCLhtG+gG4gtpz7LNc1qXlJZkGtvtw0QM6i nC/VP3x51yCWrWcouFLPx4vNlDN0aiE6kLgX/o/G5nQkKllvcR+vERN+VMALzbN9 4z91A/4+ZIbMObtahOqGD/wgOCcuurNjChMccULLS3fSNAbpW63DyI8DmWF3R1vR NCBDyuDHNMK/RrcVKYFFb2rh0oC5BJlogH+/RgNFbX3S0e8tMODsFy0qddW+Eepd bJ+ha2wTNaQS9L/vMUA+GVecMbsT7luk4hdevooSE9VeZI3uK7QkUmljaGFyZCBI dWdoZXMgPHJpY2hhcmRAaHVnaHNpZS5jb20+iFsEExECABsFAkGBLRIGCwkIBwMC AxUCAwMWAgECHgECF4AACgkQAt/QGHujzbumOQCeNgo7D7ELHlHb6FaAEKJ7SUs4 NXkAn0Wn1ciNOX6JKSptrSVekn9Tp/zguQENBEGBLRMQBACHVd4oNEXvmDUx/J6+ SDCvH8gP7oXonMex9oTz2+2q3t1tUwGMUCEdI3mzGf/oiuZzvnb3dcjEt7ifvtrb jIwkDs9X9xS3c0t0+ZzHLg0NXv3aBtg4lEVIy3iOoL67un5vbn6ZrQbmqCFxQwWf 4RGx6mZUYv9Eld513jCX8yUirwADBQP7BrcKgHQKC1v1q9BPqUizh24bKR6pvd2j Tk4sBcpdN8zmTR4C4mBTdW8XobUFM5gEIbzbnV3cmhm8AVQZFy5w2y6IVR9p/UHR J8x51HZn4Wt8P6uScHmpzWZw79FlAC+LBlgj+lzHq00TEuJUQ2/VNxvJu9jvMTXf nV99ZZccArmIRgQYEQIABgUCQYEtEwAKCRAC39AYe6PNu6WxAJ0TJOJWJgNALUpf jtpMT+065uGB5ACffDuB1eq9nMSCEywoCHZ0DCj98GY= =ctLc -----END PGP PUBLIC KEY BLOCK----- ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: acpi.diff Type: application/octet-stream Size: 599 bytes Desc: acpi.diff Url : http://lists.freedesktop.org/archives/hal/attachments/20050513/74a1696d/acpi.obj -------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From richard.hughes4 at baesystems.com Fri May 13 02:49:34 2005 From: richard.hughes4 at baesystems.com (Hughes, Richard (UK Rochester)) Date: Mon Aug 15 18:49:25 2005 Subject: [Gnome-Power-Devel] Re: HAL + Gnome-POwer Message-ID: Stefan Seyfried writes: > Ow Mun Heng wrote: > > The below piece of code (_very_ crude) will add that support into HAL > > via the "Computer" top level (the same area where acpi support is > > determined) > Just a short notice: swsusp and suspend2 have absolutely nothing to do > with ACPI. They work with APM and (at least swsusp) even without any of > them, so "acpi.c" seems to be the wrong place IMO. > > We made all the same mistakes some 18 months ago in the first > incarnation of powersaved Okay thanks, agreed. I'll come up with a better patch for HAL this afternoon. Also, can we cc all HAL related stuff to hal@lists.freedesktop.org from now on please. Thanks, Richard. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Fri May 13 06:03:50 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] Re: suspend2 checks In-Reply-To: References: Message-ID: <1115989430.3479.2.camel@localhost.localdomain> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Fri May 13 06:39:24 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] Re: suspend2 checks In-Reply-To: <1115989430.3479.2.camel@localhost.localdomain> References: <1115989430.3479.2.camel@localhost.localdomain> Message-ID: <1115991564.3479.6.camel@localhost.localdomain> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Fri May 13 07:26:00 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: suspend2 checks In-Reply-To: References: Message-ID: <1115994360.4238.10.camel@daxter.boston.redhat.com> Hi, On Fri, 2005-05-13 at 10:01 +0100, Hughes, Richard (UK Rochester) wrote: > I've been sent a patch by Ow Mun Heng (to the gnome-power mailing > list) to add the check for suspend2 in acpi.c > As discussed earlier, I think it makes sense for hal to abstract system power management including suspend/hibernation and what have you. I'm not sure though that we need too many details and we also want an abstract interface. So, what about exposing bool power_management.sleep.can_quick_sleep (in ACPI this is S1) bool power_management.sleep.can_deep_sleep (in ACPI this is S3) bool power_management.sleep.can_hibernate (in ACPI this is S4) along with methods QuickSleep() DeepSleep() Hibernate() on the org.freedesktop.Hal.PowerManagement interface (I'm have some code to commit so we can do this soon). I'm not really sure we need to know whether swsup or suspend2 is used for the hibernate implementation, do you feel this is necessary for gnome-power-manager? (we need to come up with better names than QuickSleep, DeepSleep though) Cheers, David > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** I would suggest not using standard disclaimers like these on public mailing lists :-) _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Fri May 13 07:37:33 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] Re: suspend2 checks In-Reply-To: <1115991564.3479.6.camel@localhost.localdomain> References: <1115989430.3479.2.camel@localhost.localdomain> <1115991564.3479.6.camel@localhost.localdomain> Message-ID: <1115995053.4238.21.camel@daxter.boston.redhat.com> On Fri, 2005-05-13 at 14:39 +0100, Richard Hughes wrote: > On Fri, 2005-05-13 at 14:03 +0100, Richard Hughes wrote: > > On Fri, 2005-05-13 at 10:01 +0100, Hughes, Richard (UK Rochester) wrote: > > > Is this something that belongs in HAL? I know that hal-spec.xml.in > > > would need patching too, but included the patch as received for now. > > > > After an email from Stefan Seyfried, (who reminded me that suspend2 was > > not just acpi), I've changed the original patch to the one attached. > > > > Comments most welcome. > > Thanks for the patch. As discussed, how about a patch that sets bool power_management.sleep.can_quick_sleep (in ACPI this is S1) bool power_management.sleep.can_deep_sleep (in ACPI this is S3) bool power_management.sleep.can_hibernate (in ACPI this is S4) Here's how I would choose the values quick_sleep: true only if /sys/power/state contains 'standby' deep_sleep: true only if /sys/power/state contains 'mem' hibernate: use the algorithm in your patch (extra points for code to detect swsup also) Thanks, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Fri May 13 07:39:36 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:25 2005 Subject: suspend2 checks In-Reply-To: <1115994360.4238.10.camel@daxter.boston.redhat.com> References: <1115994360.4238.10.camel@daxter.boston.redhat.com> Message-ID: <1115995176.3479.14.camel@localhost.localdomain> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Fri May 13 07:46:20 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: ACPI inconsistent button state In-Reply-To: <200505130910.32623.rohan.pm@gmail.com> References: <200505130910.32623.rohan.pm@gmail.com> Message-ID: <1115995580.4238.31.camel@daxter.boston.redhat.com> On Fri, 2005-05-13 at 09:10 +1000, Rohan McGovern wrote: > Hi all, > > I've been using Ivman to hibernate my laptop, and an issue with HAL's ACPI > support has come to light. Basically, when I close the lid of my laptop, it > will hibernate; when I open the lid of my laptop and turn it back on, it will > resume, and HAL will still think the lid is closed (presumably because it was > opened while the power was off). Specifically, button.state.value = true > on /org/freedesktop/Hal/devices/acpi_LID, when it should be false. > > Luckily this is trivial to work around (just have a hal-set-property command > after the hibernate script), but a fix in the HAL source would be nice :-) > The '/proc/acpi/button/lid/LID/state' file gives the correct state for the > lid no matter what, so this is definitely fixable at HAL's level. It seems > to me like this could be fixed by calling acpi_rescan_device (or > button_refresh) on the lid device at some point, but from looking at the > output of lshal --monitor while hibernating, there doesn't appear to be any > obvious event which consistently occurs where it makes sense to do this. It > could be done in acpi_poll, but hopefully someone with greater insight and > knowledge of HAL can think of a more efficient way :-) > > This problem probably extends to all ACPI buttons with button.has_state = > true . Hi, thanks for the testing. It looks like the kernel isn't emitting an ACPI event when the 'lid button' is released which is pretty understandable (since the box is physically powered off when the lid is opened :-). I think we may require the hibernate script to simply poke hald. The alternative is to fix the kernel driver of course (just make it event an ACPI event at the right time) - this may be the right fix :-) However, right now, poking hald is a bit complex from a shell script. How about a command line util hal-find-by-capability a'la hal-set-property so you can find all the UDI's you need to invoke Rescan() on? I imagine it would be something like this BUTTON_UDIS=`hal-find-by-capability --capability button` for UDI in $BUTTON_UDIS; do dbus-send --system --dest org.freedesktop.Hal $UDI \ org.freedesktop.Hal.Device.Rescan done Would that be useful? (warning; completely untested code) Thanks, David > > -- Rohan McGovern > _______________________________________________ > hal mailing list > hal@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/hal _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Fri May 13 07:49:42 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] Re: suspend2 checks In-Reply-To: <1115995053.4238.21.camel@daxter.boston.redhat.com> References: <1115989430.3479.2.camel@localhost.localdomain> <1115991564.3479.6.camel@localhost.localdomain> <1115995053.4238.21.camel@daxter.boston.redhat.com> Message-ID: <1115995782.3479.19.camel@localhost.localdomain> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From danny.milo at gmx.net Fri May 13 07:53:46 2005 From: danny.milo at gmx.net (Danny Milosavljevic) Date: Mon Aug 15 18:49:25 2005 Subject: hal-device-manager has just 1 node ? Message-ID: <1115996026.16821.4.camel@pyramid.niea.at> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From danny.milo at gmx.net Fri May 13 08:02:15 2005 From: danny.milo at gmx.net (Danny Milosavljevic) Date: Mon Aug 15 18:49:25 2005 Subject: hal-device-manager has just 1 node ? In-Reply-To: <1115996026.16821.4.camel@pyramid.niea.at> References: <1115996026.16821.4.camel@pyramid.niea.at> Message-ID: <1115996535.17005.3.camel@pyramid.niea.at> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Fri May 13 08:06:15 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: hal-device-manager has just 1 node ? In-Reply-To: <1115996535.17005.3.camel@pyramid.niea.at> References: <1115996026.16821.4.camel@pyramid.niea.at> <1115996535.17005.3.camel@pyramid.niea.at> Message-ID: <1115996775.4238.43.camel@daxter.boston.redhat.com> On Fri, 2005-05-13 at 17:02 +0200, Danny Milosavljevic wrote: > 16:58:35.053 [E] coldplug.c:154: Expected '=', not '\n' in line Are you using udev 057 or later? (as mentioned in the NEWS file) Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Fri May 13 08:58:55 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: ACPI inconsistent button state In-Reply-To: <1115995580.4238.31.camel@daxter.boston.redhat.com> References: <200505130910.32623.rohan.pm@gmail.com> <1115995580.4238.31.camel@daxter.boston.redhat.com> Message-ID: <1115999935.4238.47.camel@daxter.boston.redhat.com> Hi, I just add hal-find-by-capability and hal-find-by-property to CVS so it should be easy to do this now. Here's an example [davidz@daxter tools]$ ./hal-find-by-capability --capability button /org/freedesktop/Hal/devices/acpi_SLPB /org/freedesktop/Hal/devices/acpi_PWRF /org/freedesktop/Hal/devices/acpi_LID [davidz@daxter tools]$ ./hal-find-by-property --key info.bus --string usb /org/freedesktop/Hal/devices/usb_device_0_0_0000_00_1d_0_if0 /org/freedesktop/Hal/devices/usb_device_0_0_0000_00_1d_1_if0 /org/freedesktop/Hal/devices/usb_device_0_0_0000_00_1d_2_if0 /org/freedesktop/Hal/devices/usb_device_0_0_0000_00_1d_7_if0 [davidz@daxter tools]$ ./hal-find-by-capability --capability storage /org/freedesktop/Hal/devices/storage_serial_NP0JT48299J8 /org/freedesktop/Hal/devices/storage_model_HL_DT_STCD_RW/DVD_DRIVE_GCC_4242N Hope this helps, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From danny.milo at gmx.net Fri May 13 09:45:57 2005 From: danny.milo at gmx.net (Danny Milosavljevic) Date: Mon Aug 15 18:49:25 2005 Subject: hal-device-manager has just 1 node ? In-Reply-To: <1115996775.4238.43.camel@daxter.boston.redhat.com> References: <1115996026.16821.4.camel@pyramid.niea.at> <1115996535.17005.3.camel@pyramid.niea.at> <1115996775.4238.43.camel@daxter.boston.redhat.com> Message-ID: <1116002757.23613.1.camel@pyramid.niea.at> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From danny.milo at gmx.net Fri May 13 10:56:40 2005 From: danny.milo at gmx.net (Danny Milosavljevic) Date: Mon Aug 15 18:49:25 2005 Subject: hal-device-manager has just 1 node ? In-Reply-To: <1116002757.23613.1.camel@pyramid.niea.at> References: <1115996026.16821.4.camel@pyramid.niea.at> <1115996535.17005.3.camel@pyramid.niea.at> <1115996775.4238.43.camel@daxter.boston.redhat.com> <1116002757.23613.1.camel@pyramid.niea.at> Message-ID: <1116007000.19960.1.camel@pyramid.niea.at> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From yez at home.nl Fri May 13 14:09:57 2005 From: yez at home.nl (Edwin Schepers) Date: Mon Aug 15 18:49:25 2005 Subject: unknown property camera.access_method In-Reply-To: <1115926099.4248.22.camel@daxter.boston.redhat.com> References: <200505111435.22378.yez@home.nl> <1115926099.4248.22.camel@daxter.boston.redhat.com> Message-ID: <200505132109.57692.yez@home.nl> On Thursday 12 May 2005 19:28, David Zeuthen wrote: > Yeah, the device information files for cameras doesn't ship with hal > 0.5.1. I've added the PTP one to hal cvs (will be part of the 0.5.2 > release) and I've also added Pozsar Balazs script to generate the device > information file from libgphoto2 to the tools/ directory. > > I am working on a patch to submit to libgphoto2 such that the device > information file is installed with the library (in Fedora Rawhide we > ship patched version of libgphoto2 that does exactly this). Ok, I'll try 0.5.2 Thanks, Edwin _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From danny.milo at gmx.net Fri May 13 12:07:48 2005 From: danny.milo at gmx.net (Danny Milosavljevic) Date: Mon Aug 15 18:49:25 2005 Subject: Fwd: Exposing the mouse battery status through HAL In-Reply-To: <48890e6405011316095ef10345@mail.gmail.com> References: <48890e64041130081273b3ec09@mail.gmail.com> <1102004221.12241.38.camel@davidz> <48890e64041202085219564d47@mail.gmail.com> <1102008298.12241.78.camel@davidz> <48890e640412021249202fee11@mail.gmail.com> <1102044770.3581.15.camel@davidz> <48890e64041212145022ddfe6f@mail.gmail.com> <1103562042.20897.20.camel@daxter.boston.redhat.com> <48890e640412200949489f21c8@mail.gmail.com> <48890e6405011316082786d939@mail.gmail.com> <48890e6405011316095ef10345@mail.gmail.com> Message-ID: <1116011268.20401.2.camel@pyramid.niea.at> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From danny.milo at gmx.net Fri May 13 12:09:17 2005 From: danny.milo at gmx.net (Danny Milosavljevic) Date: Mon Aug 15 18:49:25 2005 Subject: hal-device-manager has just 1 node ? In-Reply-To: <1116007000.19960.1.camel@pyramid.niea.at> References: <1115996026.16821.4.camel@pyramid.niea.at> <1115996535.17005.3.camel@pyramid.niea.at> <1115996775.4238.43.camel@daxter.boston.redhat.com> <1116002757.23613.1.camel@pyramid.niea.at> <1116007000.19960.1.camel@pyramid.niea.at> Message-ID: <1116011357.20478.5.camel@pyramid.niea.at> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From rohan.pm at gmail.com Fri May 13 16:27:42 2005 From: rohan.pm at gmail.com (Rohan McGovern) Date: Mon Aug 15 18:49:25 2005 Subject: ACPI inconsistent button state In-Reply-To: <1115999935.4238.47.camel@daxter.boston.redhat.com> References: <200505130910.32623.rohan.pm@gmail.com> <1115995580.4238.31.camel@daxter.boston.redhat.com> <1115999935.4238.47.camel@daxter.boston.redhat.com> Message-ID: <200505140927.43446.rohan.pm@gmail.com> On Sat, 14 May 2005 01:58, you wrote: > Hi, > > I just add hal-find-by-capability and hal-find-by-property to CVS so it > should be easy to do this now. Here's an example > ... > Hope this helps, > David Excellent :-) Thank you for that. Hopefully it will become less of an issue now anyway; since you and Richard are talking about implementing a Hibernate method within HAL, presumably it should take care of issues like this. -- Rohan _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From ma at dt.e-technik.uni-dortmund.de Sun May 15 04:06:46 2005 From: ma at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Mon Aug 15 18:49:25 2005 Subject: Please fix bug #1852 (hald causes SYM53C8xx SCSI errors, device disconnects + GNOME hang) Message-ID: <20050515110646.GC14132@merlin.emma.line.org> Greetings, Please, can someone have a look at bug #1852 *now*? This has been haunting users of the fine 53C8XX SCSI adapters for much too long. Thanks a bunch in advance. Quoting from Bugzilla #1852 - this should give sufficient information to fix the bug. As it totally bogs down my machine if I log into GNOME after boot-up, I've bumped Bugzilla severity up one level, to critical. Kind regards, Matthias Andree ----- OS: SUSE Linux 9.3 Kernels tried (same results): SUSE's kernel-default-2.6.11.4-20a as well as a vanilla 2.6.11.9 hal-0.4.7-26 (SUSE) udev-053-15.2 (SUSE) hotplug-0.50-19 (SUSE) Relevant discussion around hwscan(d) took place on Linux-SCSI in November 2004, see particularly - note thought that the assertion in the discussion 53C876 and higher fixed this is wrong, I can reproduce the problem on a 53C895 (as well as 53C860, 53C875, Matt Wilcox reproduced it on a 53C810A). hald attempts to read 4,096 bytes from the /sys/devices/pci0000:00/0000:00:0d.0/config file (which pertains to my SYM53C895 based Symbios SCSI adaptor) and gets 256 if run as root (64 if run as regular user). In these upper 128 bytes, some of the SYM53C8XX adaptors mirror their register block, and reading one of the registers causes the parity error, with major consequences such as GNOME hanging, CD-ROM disappearing from the bus, syslog excerpt below. Please make hald read only 128 (or perhaps 64 if sufficient) bytes from the /config file of SYM53C8XX devices. strace: 12750 12:12:48.546305 lstat64("/sys/devices/pci0000:00/0000:00:0d.0/config", {st_mode=S_IFREG|0644, st_size=256, ...}) = 0 12750 12:12:48.546377 stat64("/sys/devices/pci0000:00/0000:00:0d.0/config", {st_mode=S_IFREG|0644, st_size=256, ...}) = 0 12750 12:12:48.546449 open("/sys/devices/pci0000:00/0000:00:0d.0/config", O_RDONLY) = 12 12750 12:12:48.546497 read(12, "\0\20\f\0\27\0\0\2\1\0\0\1\20 \0\0\1\320\0\0\0\0\200\354"..., 4096) = 256 12750 12:12:48.553789 close(12) = 0 syslog: May 14 19:56:47 merlin kernel: sym0: SCSI parity error detected: SCR1=132 DBC=50000000 SBCL=0 May 14 19:57:18 merlin kernel: sym0:2:0: ABORT operation started. May 14 19:57:23 merlin kernel: sym0:2:0: ABORT operation timed-out. May 14 19:57:23 merlin kernel: sym0:2:0: DEVICE RESET operation started. May 14 19:57:28 merlin kernel: sym0:2:0: DEVICE RESET operation timed-out. May 14 19:57:28 merlin kernel: sym0:2:0: BUS RESET operation started. May 14 19:57:28 merlin kernel: sym0: SCSI BUS reset detected. May 14 19:57:28 merlin kernel: sym0: SCSI BUS has been reset. May 14 19:57:28 merlin kernel: sym0:2:0: BUS RESET operation complete. May 14 19:57:38 merlin kernel: sym0:2:0: HOST RESET operation started. May 14 19:57:48 merlin kernel: scsi: Device offlined - not ready after error recovery: host 0 channel 0 id 2 lun 0 May 14 19:57:48 merlin kernel: scsi0 (2:0): rejecting I/O to offline device May 14 19:57:48 merlin last message repeated 4 times May 14 19:57:48 merlin kernel: cdrom: open failed. May 14 19:57:48 merlin kernel: scsi0 (2:0): rejecting I/O to offline device May 14 19:57:50 merlin kernel: cdrom: open failed. May 14 19:57:50 merlin kernel: scsi0 (2:0): rejecting I/O to offline device ... and so on every two seconds lspci: 0000:00:0d.0 SCSI storage controller: LSI Logic / Symbios Logic 53c895 (rev 01) Subsystem: Tekram Technology Co.,Ltd. DC-390U2W Flags: bus master, medium devsel, latency 32, IRQ 16 I/O ports at d000 [size=256] Memory at ec800000 (32-bit, non-prefetchable) [size=256] Memory at ec000000 (32-bit, non-prefetchable) [size=4K] lshal excerpt: udi = '/org/freedesktop/Hal/devices/pci_1000_c' info.parent = '/org/freedesktop/Hal/devices/computer' (string) info.udi = '/org/freedesktop/Hal/devices/pci_1000_c' (string) pci.device_protocol = 0 (0x0) (int) pci.device_subclass = 0 (0x0) (int) pci.device_class = 1 (0x1) (int) info.vendor = 'LSI Logic / Symbios Logic' (string) info.product = '53c895' (string) pci.subsys_product = 'DC-390U2W' (string) pci.subsys_vendor = 'Tekram Technology Co.,Ltd.' (string) pci.product = '53c895' (string) pci.vendor = 'LSI Logic / Symbios Logic' (string) pci.subsys_product_id = 14599 (0x3907) (int) pci.subsys_vendor_id = 7649 (0x1de1) (int) pci.product_id = 12 (0xc) (int) pci.vendor_id = 4096 (0x1000) (int) pci.linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:0d.0' (string) linux.sysfs_path_device = '/sys/devices/pci0000:00/0000:00:0d.0' (string) linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:0d.0' (string) info.bus = 'pci' (string) hald output: 12:12:48.528 [I] linux/osspec.c:795: handling /sys/devices/pci0000:00/0000:00:0d.0 pci 12:12:48.560 [I] device_info.c:1175: scan_fdi_files: Processing file '6in1-card-reader.fdi' 12:12:48.565 [I] device_info.c:1175: scan_fdi_files: Processing file 'ide-drives.fdi' 12:12:48.572 [I] device_info.c:1175: scan_fdi_files: Processing file 'jetflash-mp3-player.fdi' 12:12:48.576 [I] device_info.c:1175: scan_fdi_files: Processing file 'lexar-media-cf-reader.fdi' 12:12:48.581 [I] device_info.c:1175: scan_fdi_files: Processing file 'lucent-pcmcia-wireless.fdi' 12:12:48.586 [I] device_info.c:1175: scan_fdi_files: Processing file 'sony_dsc.fdi' 12:12:48.591 [I] device_info.c:1175: scan_fdi_files: Processing file 'usb-zip-drives.fdi' 12:12:48.598 [I] device_info.c:1175: scan_fdi_files: Processing file 'storage-policy.fdi' 12:12:48.604 [I] device_info.c:1175: scan_fdi_files: Processing file 'ipod.fdi' 12:12:48.608 [E] device_info.c:334: Could not resolve keypath '@info.parent:storage.model' on udi '/org/freedesktop/Hal/devices/pci_1000_c' 12:12:48.618 [I] callout.c:318: Invoking /etc/hal/device.d/90-block-subfs.hal 12:12:48.657 [I] callout.c:330: Child pid 13098 for 90-block-subfs.hal 12:12:48.662 [I] callout.c:193: Callouts done for /org/freedesktop/Hal/devices/pci_109e_36e 12:12:48.667 [W] hald_dbus.c:97: No property volume.is_disc on device with id /org/freedesktop/Hal/devices/pci_109e_36e 12:12:48.678 [I] callout.c:173: Child pid 13098 terminated 12:12:48.683 [I] callout.c:318: Invoking /etc/hal/device.d/40-hal-hotplug-map.hal 12:12:48.722 [I] callout.c:330: Child pid 13099 for 40-hal-hotplug-map.hal 12:12:48.730 [I] callout.c:173: Child pid 13099 terminated 12:12:48.735 [I] hald.c:81: Added device to GDL; udi=/org/freedesktop/Hal/devices/pci_1000_c -- Matthias Andree _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Sun May 15 07:11:35 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] addon-acpi.c : fix checking of ac_adapter and button Message-ID: <1116166295.2763.4.camel@localhost.localdomain> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Sun May 15 09:42:40 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: Please fix bug #1852 (hald causes SYM53C8xx SCSI errors, device disconnects + GNOME hang) In-Reply-To: <20050515110646.GC14132@merlin.emma.line.org> References: <20050515110646.GC14132@merlin.emma.line.org> Message-ID: <1116175360.4323.9.camel@daxter.boston.redhat.com> On Sun, 2005-05-15 at 13:06 +0200, Matthias Andree wrote: > Greetings, > > Please, can someone have a look at bug #1852 *now*? This has been > haunting users of the fine 53C8XX SCSI adapters for much too long. > Thanks a bunch in advance. > > Quoting from Bugzilla #1852 - this should give sufficient information to > fix the bug. As it totally bogs down my machine if I log into GNOME > after boot-up, I've bumped Bugzilla severity up one level, to critical. https://bugs.freedesktop.org/show_bug.cgi?id=1852 Yeah, this should probably be fixed ASAP, it shouldn't be too difficult. Does anyone have a patch? Otherwise I'll look at it tonight (EDT). Then I'll do a new 0.4.8 release too. Btw, this shouldn't affect hal 0.5.x as we don't use libsysfs there. It may affect udev - Kay? Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From ma at dt.e-technik.uni-dortmund.de Sun May 15 10:31:49 2005 From: ma at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Mon Aug 15 18:49:25 2005 Subject: Please fix bug #1852 (hald causes SYM53C8xx SCSI errors, device disconnects + GNOME hang) In-Reply-To: <1116175360.4323.9.camel@daxter.boston.redhat.com> References: <20050515110646.GC14132@merlin.emma.line.org> <1116175360.4323.9.camel@daxter.boston.redhat.com> Message-ID: <20050515173148.GA23784@merlin.emma.line.org> On Sun, 15 May 2005, David Zeuthen wrote: > Yeah, this should probably be fixed ASAP, it shouldn't be too difficult. > Does anyone have a patch? Otherwise I'll look at it tonight (EDT). Then > I'll do a new 0.4.8 release too. I don't have a patch, sorry. I hacked up my system with new udev, dbus and hal to see, and it doesn't seem to read the config file at all (I used strace -fF). So is the bug in libsysfs instead? If so, a bug report should probably be sent that way, too. > Btw, this shouldn't affect hal 0.5.x as we don't use libsysfs there. It > may affect udev - Kay? At any rate, there's no user-relevant data after byte #128 in SYM53C8XX's /sys/devices/pci*/.../config files. These are all zero on newer adaptors according to Matt Wilcox, SYM53C8XX maintainer, so no entropy there that might make an application or auxiliary subsystem change behavior. BTW, "tak" for the quick response! -- Matthias Andree _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From kay.sievers at vrfy.org Sun May 15 10:53:25 2005 From: kay.sievers at vrfy.org (Kay Sievers) Date: Mon Aug 15 18:49:25 2005 Subject: Please fix bug #1852 (hald causes SYM53C8xx SCSI errors, device disconnects + GNOME hang) In-Reply-To: <1116175360.4323.9.camel@daxter.boston.redhat.com> References: <20050515110646.GC14132@merlin.emma.line.org> <1116175360.4323.9.camel@daxter.boston.redhat.com> Message-ID: <1116179605.15470.28.camel@dhcp-188.off.vrfy.org> On Sun, 2005-05-15 at 12:42 -0400, David Zeuthen wrote: > On Sun, 2005-05-15 at 13:06 +0200, Matthias Andree wrote: > > Greetings, > > > > Please, can someone have a look at bug #1852 *now*? This has been > > haunting users of the fine 53C8XX SCSI adapters for much too long. > > Thanks a bunch in advance. > > > > Quoting from Bugzilla #1852 - this should give sufficient information to > > fix the bug. As it totally bogs down my machine if I log into GNOME > > after boot-up, I've bumped Bugzilla severity up one level, to critical. > > https://bugs.freedesktop.org/show_bug.cgi?id=1852 > > Yeah, this should probably be fixed ASAP, it shouldn't be too difficult. > Does anyone have a patch? Otherwise I'll look at it tonight (EDT). Then > I'll do a new 0.4.8 release too. > > Btw, this shouldn't affect hal 0.5.x as we don't use libsysfs there. It > may affect udev - Kay? We've fixed udev's libsysfs not to read _everything_ it finds, a while ago. udev will not cause this error. :) But every other user of libsysfs is expected to trigger it, cause the fixes are not released by now. They are only in the CVS of libsysfs. SUSE 9.3 has 0.4.7 with the bad libsysfs an hwinfo and other tools too. They all need to be fixed. For the old HAL we may just patch our included libsysfs to skip any file that is named "config"? Kay _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Mon May 16 08:15:50 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: Please fix bug #1852 (hald causes SYM53C8xx SCSI errors, device disconnects + GNOME hang) In-Reply-To: <20050515173148.GA23784@merlin.emma.line.org> References: <20050515110646.GC14132@merlin.emma.line.org> <1116175360.4323.9.camel@daxter.boston.redhat.com> <20050515173148.GA23784@merlin.emma.line.org> Message-ID: <1116256550.4261.21.camel@daxter.boston.redhat.com> On Sun, 2005-05-15 at 19:31 +0200, Matthias Andree wrote: > On Sun, 15 May 2005, David Zeuthen wrote: > > > Yeah, this should probably be fixed ASAP, it shouldn't be too difficult. > > Does anyone have a patch? Otherwise I'll look at it tonight (EDT). Then > > I'll do a new 0.4.8 release too. OK, my only system with the old dbus and hal is at work so it had to wait for this morning. > > I don't have a patch, sorry. > > I hacked up my system with new udev, dbus and hal to see, and it doesn't > seem to read the config file at all (I used strace -fF). > > So is the bug in libsysfs instead? If so, a bug report should probably > be sent that way, too. Can you try the attached patch? If it works I'll commit it and roll a new release. > > Btw, this shouldn't affect hal 0.5.x as we don't use libsysfs there. It > > may affect udev - Kay? > > At any rate, there's no user-relevant data after byte #128 in > SYM53C8XX's /sys/devices/pci*/.../config files. These are all zero on > newer adaptors according to Matt Wilcox, SYM53C8XX maintainer, so no > entropy there that might make an application or auxiliary subsystem > change behavior. > The kernel should really be fixed such that simply reading the 'config' attribute doesn't result in this. I'm also worried about this because even unprivileged users may read "config" attributes as the mode is 0644. > BTW, "tak" for the quick response! > Heh, "kein problem" :-) Cheers, David -------------- next part -------------- A non-text attachment was scrubbed... Name: hal-0.4.7-do-not-read-config-file.patch Type: text/x-patch Size: 669 bytes Desc: not available Url : http://lists.freedesktop.org/archives/hal/attachments/20050516/b68022c6/hal-0.4.7-do-not-read-config-file.bin -------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Mon May 16 10:42:22 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:25 2005 Subject: [patch] addon-acpi.c : fix checking of ac_adapter and button In-Reply-To: <1116166295.2763.4.camel@localhost.localdomain> References: <1116166295.2763.4.camel@localhost.localdomain> Message-ID: <1116265342.4261.29.camel@daxter.boston.redhat.com> On Sun, 2005-05-15 at 15:11 +0100, Richard Hughes wrote: > Whilst using CVS, I've found that ACPI ac_adapter events are not > triggering a rescan of the ac_adapter object. > > Below is a patch to fix ac_adapter and also change the the strncmp > checking of button to match that of battery. Look at the trailing slash > in both cases. > > Please check and apply. This is now in CVS. Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From ma at dt.e-technik.uni-dortmund.de Mon May 16 11:59:45 2005 From: ma at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Mon Aug 15 18:49:25 2005 Subject: Please fix bug #1852 (hald causes SYM53C8xx SCSI errors, device disconnects + GNOME hang) In-Reply-To: <1116179605.15470.28.camel@dhcp-188.off.vrfy.org> References: <20050515110646.GC14132@merlin.emma.line.org> <1116175360.4323.9.camel@daxter.boston.redhat.com> <1116179605.15470.28.camel@dhcp-188.off.vrfy.org> Message-ID: <20050516185945.GA15532@merlin.emma.line.org> On Sun, 15 May 2005, Kay Sievers wrote: > We've fixed udev's libsysfs not to read _everything_ it finds, a while > ago. udev will not cause this error. :) > But every other user of libsysfs is expected to trigger it, cause the > fixes are not released by now. They are only in the CVS of libsysfs. > > SUSE 9.3 has 0.4.7 with the bad libsysfs an hwinfo and other tools too. > They all need to be fixed. SUSE fixed hwinfo in 9.2 and backported the fix to 9.1. If however so many applications are affected, I wonder if the kernel should really offer data beyond the configuration space in a file named "config". -- Matthias Andree _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From ma at dt.e-technik.uni-dortmund.de Mon May 16 12:01:30 2005 From: ma at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Mon Aug 15 18:49:26 2005 Subject: patch for #1852 works, thanks! (was: Please fix bug #1852 (hald causes SYM53C8xx SCSI errors, device disconnects + GNOME hang)) In-Reply-To: <1116256550.4261.21.camel@daxter.boston.redhat.com> References: <20050515110646.GC14132@merlin.emma.line.org> <1116175360.4323.9.camel@daxter.boston.redhat.com> <20050515173148.GA23784@merlin.emma.line.org> <1116256550.4261.21.camel@daxter.boston.redhat.com> Message-ID: <20050516190130.GB15532@merlin.emma.line.org> Short: the patch works for me. Thank you! Long: read on :-) On Mon, 16 May 2005, David Zeuthen wrote: > The kernel should really be fixed such that simply reading the 'config' > attribute doesn't result in this. I'm also worried about this because > even unprivileged users may read "config" attributes as the mode is > 0644. I'm told the PCI configuration space is 256 bytes, so this is probably the place that needs to be attacked as well. Matthew Wilcox (53C8XX maintainer) mentioned something like hacking the code to hide the upper 128 bytes in the .../config files for these adapters in November 2004, but hasn't done this until 2.6.11. I started a new discussion on and asked to implement this, I believe on in-depth fixes. hal was merely a "consumer" of this data. > diff -u -p -r1.3.2.1 sysfs_dir.c > --- hald/linux/libsysfs/sysfs_dir.c 20 Jan 2005 17:03:54 -0000 1.3.2.1 > +++ hald/linux/libsysfs/sysfs_dir.c 16 May 2005 15:03:14 -0000 > @@ -624,6 +624,8 @@ int sysfs_read_dir_attributes(struct sys > continue; > if (0 == strcmp(dirent->d_name, "..")) > continue; > + if (0 == strcmp(dirent->d_name, "config")) > + continue; > memset(file_path, 0, SYSFS_PATH_MAX); > safestrcpy(file_path, sysdir->path); > safestrcat(file_path, "/"); This patch works for me. Interesting that hal was reading files it doesn't need, so as a side effect, it should be a tiny bit more efficient now. Thanks again. For those interested in trying the patch not having sufficient expertise with patch/rebuild procedures, I have uploaded patched RPMS for SUSE Linux 9.3 to http://home.pages.de/~mandree/suse-9.3-i586.de/ - just download all the hal* packages and type rpm -Uhv hal*.i586.rpm I chose the version numbers to that the full SUSE update packages will be considered newer than mine, but delta and patch RPMs will not work for these, you'd have to use the full .i586.rpm files. -- Matthias Andree _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Tue May 17 08:02:21 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:26 2005 Subject: hal 0.4.8 "Without your space helmet, Dave, you're going to find that rather difficult." released Message-ID: <1116342141.4295.13.camel@daxter.boston.redhat.com> Hi, Here's a new release from the stable branch. Mainly minor bug fixes. Download from http://freedesktop.org/~david/dist/hal-0.4.8.tar.gz Changes from 0.4.7 - Fix network link detection (Bill Moss) - Add the net.80203.can_detect_link - Fix a problem with trailing commas in libhal-storage (Sebastian Dransfeld) - Use better names for USB Zip Drives (Daniel Serpell) - Fix some memory leaks when handling device information files - zh_TW translation (chaoweilun@pcmail.com.tw) - Add /var/lib/misc to pci.ids search path (Murray Cumming, fd.o #2547) - Never read sysfs attributes called "config" (Matthias Andree, fd.o #1852) Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From snwint at suse.de Tue May 17 08:49:36 2005 From: snwint at suse.de (Steffen Winterfeldt) Date: Mon Aug 15 18:49:26 2005 Subject: Please fix bug #1852 (hald causes SYM53C8xx SCSI errors, device disconnects + GNOME hang) In-Reply-To: <1116179605.15470.28.camel@dhcp-188.off.vrfy.org> References: <20050515110646.GC14132@merlin.emma.line.org> <1116175360.4323.9.camel@daxter.boston.redhat.com> <1116179605.15470.28.camel@dhcp-188.off.vrfy.org> Message-ID: On Sun, 15 May 2005, Kay Sievers wrote: > SUSE 9.3 has 0.4.7 with the bad libsysfs an hwinfo and other tools too. > They all need to be fixed. hwinfo already has a workaround for this particular problem. If you really need the pci config, reading 64 bytes + the capability list should be safe. Steffen _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From danny.kukawka at web.de Thu May 19 04:50:26 2005 From: danny.kukawka at web.de (Danny Kukawka) Date: Mon Aug 15 18:49:26 2005 Subject: fix for dvd-ram entry in hal 0.4.x and 0.5.x Message-ID: <200505191350.27257.danny.kukawka@web.de> Hi, here is a fix for the dvdram entry in hal (0.4.x and 0.5.x). Currently the correct default key (storage.cdrom.dvdram = false) is created but if the device can write dvdram, hal add a new key named "storage.dvdram". Danny -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_dvdram_hal-0.4.8.diff Type: text/x-diff Size: 465 bytes Desc: not available Url : http://lists.freedesktop.org/archives/hal/attachments/20050519/8a6cbc74/fix_dvdram_hal-0.4.8.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_dvdram_hal-0.5.2.diff Type: text/x-diff Size: 543 bytes Desc: not available Url : http://lists.freedesktop.org/archives/hal/attachments/20050519/8a6cbc74/fix_dvdram_hal-0.5.2.bin -------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Fri May 20 17:25:51 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:26 2005 Subject: fix for dvd-ram entry in hal 0.4.x and 0.5.x In-Reply-To: <200505191350.27257.danny.kukawka@web.de> References: <200505191350.27257.danny.kukawka@web.de> Message-ID: <1116635151.4324.2.camel@daxter.boston.redhat.com> On Thu, 2005-05-19 at 13:50 +0200, Danny Kukawka wrote: > Hi, > > here is a fix for the dvdram entry in hal (0.4.x and 0.5.x). > > Currently the correct default key (storage.cdrom.dvdram = false) is created > but if the device can write dvdram, hal add a new key named "storage.dvdram". Nice catch, I've committed this to both hal-0_4-stable and HEAD. Thanks, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From martin at piware.de Tue May 24 01:08:32 2005 From: martin at piware.de (Martin Pitt) Date: Mon Aug 15 18:49:26 2005 Subject: Segfault fix for hal 0.5.2 Message-ID: <20050524080832.GA25214@piware.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Tue May 24 10:42:16 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:26 2005 Subject: Segfault fix for hal 0.5.2 In-Reply-To: <20050524080832.GA25214@piware.de> References: <20050524080832.GA25214@piware.de> Message-ID: <1116956536.3991.54.camel@daxter.boston.redhat.com> On Tue, 2005-05-24 at 10:08 +0200, Martin Pitt wrote: > Hi David! > > We have a report about hald segfaulting for some devices: > > https://bugzilla.ubuntu.com/show_bug.cgi?id=11060 > > In that case, serial_add() manages to read out a property value for > info.product which is NULL; hal_property_new_string() calls > g_utf8_validate() on NULL which goes BOOM. > > I fixed that at a very low level in hal_property_new_string() so that > similar issues get caught as well. I just assign an empty string to > the property if the value argument is NULL. That's pretty sensible, perhaps we should even print a warning when we encounter NULL as well? I'm not sure.. Anyway, I committed the patch you sent. Thanks, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From Daniel.Bonniot at inria.fr Thu May 26 15:36:18 2005 From: Daniel.Bonniot at inria.fr (Daniel Bonniot) Date: Mon Aug 15 18:49:26 2005 Subject: ACPI Temperature zones Message-ID: Hi, Is it currently possible to access temperature information through HAL? The abstraction would be very handy, since some systems have the information avaiable through sensors, while others have it only though ACPI (/proc/acpi/thermal_zone/THR[C|M]/temperature on my system). If not yould it make sense? Are there plans to add this? Cheers, Daniel _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Thu May 26 16:10:23 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:26 2005 Subject: ACPI Temperature zones In-Reply-To: References: Message-ID: <1117149023.4001.4.camel@localhost.localdomain> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From Daniel.Bonniot at inria.fr Thu May 26 16:46:55 2005 From: Daniel.Bonniot at inria.fr (Daniel Bonniot) Date: Mon Aug 15 18:49:26 2005 Subject: ACPI Temperature zones, batteries In-Reply-To: <1117149023.4001.4.camel@localhost.localdomain> References: <1117149023.4001.4.camel@localhost.localdomain> Message-ID: > I think the consensus was that the temperature reporting should be > linked in with the device, i.e. instead of having "temperature device > #1" and "temperature device #2" in the HAL device tree, the temperature > should be a capability of the actual object, e.g. the processor would > have keys sensor.temperature.value for example. I agree that's the best. However, as far as I know there is no automatic way to associate an ACPI thermal zone name to a concrete device (like CPU, motherboard, ...). This is claimed here, for instance: http://lists.debian.org/debian-laptop/2003/08/msg00040.html I would loved to be proved wrong. Also, maybe there is a "common practice" common enough to be taken as a default. On my system, THRC is the CPU (C), and there is also THRM is probably the motherboard (M). > If you look in the > archives you'll see what we talked about. I looked for temperature is subjects, which returns nothing. > I'm not sure if the schema for > temperature got committed to hal-spec.xml.in in the end, it might be > worth checking. > > Out of interest, what would you use the temperature sensing for? I think > everyone agreed at the time that temperature controlled emergency > shutdown was best left to the kernel. 1) Print the current temperature (in the harware-monitor gnome applet, for instance) 2) Some CPUs can be controled to change frequency and voltage (CPUfreq). I wrote a patch to the userspace tool cpudyn that controls this feature. My patch needs to know the temperature to decide which frequency to chose. BTW, I would also be interested in battery information. In that case it should be easier to attach the info to a concrete device ;-) In both cases, do you know if it's possible to be notified of changes instead of polling? Or would HAL do the polling, and notify all interested clients? Daniel _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Thu May 26 23:30:12 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:26 2005 Subject: ACPI Temperature zones, batteries In-Reply-To: References: <1117149023.4001.4.camel@localhost.localdomain> Message-ID: <1117175412.2703.6.camel@localhost.localdomain> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From Daniel.Bonniot at inria.fr Fri May 27 01:19:46 2005 From: Daniel.Bonniot at inria.fr (Daniel Bonniot) Date: Mon Aug 15 18:49:26 2005 Subject: ACPI Temperature zones, batteries In-Reply-To: <1117175412.2703.6.camel@localhost.localdomain> References: <1117149023.4001.4.camel@localhost.localdomain> <1117175412.2703.6.camel@localhost.localdomain> Message-ID: >>I agree that's the best. However, as far as I know there is no automatic way >>to associate an ACPI thermal zone name to a concrete device (like CPU, >>motherboard, ...). This is claimed here, for instance: >>http://lists.debian.org/debian-laptop/2003/08/msg00040.html >>I would loved to be proved wrong. Also, maybe there is a "common practice" >>common enough to be taken as a default. On my system, THRC is the CPU (C), and >>there is also THRM is probably the motherboard (M). > > > How does the ACPI code in the kernel generate the names? Does it know > for sure? This is just a wild guess, but I suspect the names are received through the ACPI protocol, same as the temperature data. That is, they would be somewhere in the hardware or in the bios. >>2) Some CPUs can be controled to change frequency and voltage (CPUfreq). I >>wrote a patch to the userspace tool cpudyn that controls this feature. My >>patch needs to know the temperature to decide which frequency to chose. > > > Cool - as long as you are not saying "when cpu temp > 100*c then > shutdown" :-) No, I agree this is a different job altogether. ~ cat /proc/acpi/thermal_zone/THRC/trip_points [10:11 27/05/05] critical (S5): 101 C passive: 92 C: tc1=2 tc2=5 tsp=300 devices=0xdfb47fe0 I read this as saying that the system should move to state S5 (shutdown?) if the CPU goes to 101 C. Not sure who is responsible for this, and if this is working atm on linux, luckilly I never got there. It would also be interesting to know what the passive line does. Any hint? >>BTW, I would also be interested in battery information. In that case it should >>be easier to attach the info to a concrete device ;-) > > > If I understand your question, then yes, Already there - try running > hal-0.52. See these screenshots for more information: > http://gnome-power.sourceforge.net/hal.php#screenshots Cool thanks. I see I had a quite outdated version of HAL. >>In both cases, do you know if it's possible to be notified of changes instead >>of polling? Or would HAL do the polling, and notify all interested clients? > > > Yes, this is what HAL 0.52 does, it listens on the /proc/acpi/event file > (it can work with or without acpid present) and then an event is > triggered for each change. At least on my system, I think there are events for battery insertion and moving in and out of AC, but not for each change in the battery level. Daniel _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From danny.kukawka at web.de Fri May 27 01:42:49 2005 From: danny.kukawka at web.de (Danny Kukawka) Date: Mon Aug 15 18:49:26 2005 Subject: ACPI Temperature zones, batteries In-Reply-To: <1117175412.2703.6.camel@localhost.localdomain> References: <1117175412.2703.6.camel@localhost.localdomain> Message-ID: <200505271042.49341.danny.kukawka@web.de> On Friday 27 May 2005 08:30, Richard Hughes wrote: [...] > > I agree that's the best. However, as far as I know there is no automatic > > way to associate an ACPI thermal zone name to a concrete device (like > > CPU, motherboard, ...). This is claimed here, for instance: > > http://lists.debian.org/debian-laptop/2003/08/msg00040.html > > I would loved to be proved wrong. Also, maybe there is a "common > > practice" common enough to be taken as a default. On my system, THRC is > > the CPU (C), and there is also THRM is probably the motherboard (M). > > How does the ACPI code in the kernel generate the names? Does it know > for sure? But you can't be sure that the name is correct. I have seen different machines where you can't say which thermal zone is from CPU or motherboard. If the ACPI implementation in the bios is not really good there is no clear way to assign a thermal zone to a device automatically. For such cases it would be nice if there would be a dialog to the user to assign a thermal zone (or what ever) to a device and configure HAL. Danny _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From danny.milo at gmx.net Fri May 27 02:01:28 2005 From: danny.milo at gmx.net (Danny Milosavljevic) Date: Mon Aug 15 18:49:26 2005 Subject: ACPI Temperature zones, batteries In-Reply-To: <200505271042.49341.danny.kukawka@web.de> References: <1117175412.2703.6.camel@localhost.localdomain> <200505271042.49341.danny.kukawka@web.de> Message-ID: <1117184488.20632.9.camel@pyramid.niea.at> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From danny.kukawka at web.de Fri May 27 03:13:34 2005 From: danny.kukawka at web.de (Danny Kukawka) Date: Mon Aug 15 18:49:26 2005 Subject: ACPI Temperature zones, batteries In-Reply-To: <1117184488.20632.9.camel@pyramid.niea.at> References: <200505271042.49341.danny.kukawka@web.de> <1117184488.20632.9.camel@pyramid.niea.at> Message-ID: <200505271213.35185.danny.kukawka@web.de> On Friday 27 May 2005 11:01, Danny Milosavljevic wrote: [...] > Now that would be interesting ;) > > "Please look at the values below, open up your laptop, find the cpu and > mainboard thermic sensors (usually labelled xyz, except when they are > not - be sure not to break any of the tiiny connectors) and use a > lighter to heat one of them up - do not touch the sensors themselves, > but light the air right above them. Remember which value changes below. > Then select the correct type (CPU or Mainboard or Unknown) for each of > the values. Do not burn yourself. Thanks." > > hehehe ;-) But maybe the user know more about the correct thermal zone. In some cases the temperature of a thermal zones is never changend or to high because of broken ACPI or what happens if the wrong (maybe broken) thermal zone is assigned to CPU and a other program use this values to shut down the machine? In this cases it would be nice to inform the user if something is unclear and offer to configure this with a dialog. I think its generally a good idea to make devices configurable by first detection (through a desktop/command line dialog) if there are problems to detect correct and clear properties/assignment (maybe as part of hal-device-manger). Thus we can prevent wrong or empty values. > Seriously, if it cant be determined automagically, it should probably > just be supplied by an extra file dependent on the laptop model (I think > there is a place where .fdi files are collected, correct me if I'm > wrong). Now this of course again needs the laptop model being able to be > determined. You can probably detect the laptop model through match dmidecode, but you can't add a detection and file for each existing model ;-) I think, it would be more useful for the user to configure a device trough a dialog than edit a fdi-file. Danny _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From drzeus-list at drzeus.cx Fri May 27 04:07:55 2005 From: drzeus-list at drzeus.cx (Pierre Ossman) Date: Mon Aug 15 18:49:26 2005 Subject: ACPI Temperature zones, batteries In-Reply-To: <1117175412.2703.6.camel@localhost.localdomain> References: <1117149023.4001.4.camel@localhost.localdomain> <1117175412.2703.6.camel@localhost.localdomain> Message-ID: <4296FF8B.8080405@drzeus.cx> Richard Hughes wrote: > > How does the ACPI code in the kernel generate the names? Does it know > for sure? > It is written in plaintext in the ACPI DSDT. So it's up to the designers of the machine to decide if they want to give it a decent name or not. On my laptop everything has automatically generated names so there is no system for anything. Rgds Pierre _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From hughsient at gmail.com Fri May 27 05:46:11 2005 From: hughsient at gmail.com (Richard Hughes) Date: Mon Aug 15 18:49:26 2005 Subject: ACPI Temperature zones, batteries In-Reply-To: References: <1117149023.4001.4.camel@localhost.localdomain> <1117175412.2703.6.camel@localhost.localdomain> Message-ID: <1117197971.2690.1.camel@localhost.localdomain> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From caglar at uludag.org.tr Fri May 27 15:21:49 2005 From: caglar at uludag.org.tr (=?iso-8859-9?Q?S=2E=C7a=F0lar?= Onur) Date: Mon Aug 15 18:49:27 2005 Subject: Getting Devices and Properties From a Namespace Message-ID: <1117232509.21558.39.camel@tux.uludag.org.tr> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From danny.milo at gmx.net Sat May 28 05:22:55 2005 From: danny.milo at gmx.net (Danny Milosavljevic) Date: Mon Aug 15 18:49:27 2005 Subject: ACPI Temperature zones, batteries In-Reply-To: <200505271213.35185.danny.kukawka@web.de> References: <200505271042.49341.danny.kukawka@web.de> <1117184488.20632.9.camel@pyramid.niea.at> <200505271213.35185.danny.kukawka@web.de> Message-ID: <1117282976.20741.12.camel@pyramid.niea.at> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal From david at fubar.dk Mon May 30 00:18:45 2005 From: david at fubar.dk (David Zeuthen) Date: Mon Aug 15 18:49:27 2005 Subject: Getting Devices and Properties From a Namespace In-Reply-To: <1117232509.21558.39.camel@tux.uludag.org.tr> References: <1117232509.21558.39.camel@tux.uludag.org.tr> Message-ID: <1117437525.3932.4.camel@daxter.boston.redhat.com> Hi, On Sat, 2005-05-28 at 01:21 +0300, S.?a?lar Onur wrote: > Hi; > > I'm a newbie with libhal, so please execuse me :). I want to know is > there a clean way to filter just a single namespace of any "Device > Properties" with hal-0.4.7, i read API but can't see any function to > filter. > > Currently i'm getting whole device list with > hal_device_get_all_properties(), iterate over it and using > strstr( name_of_namespace, hal_psi_get_key() ) function to filter needed > namespace from device. Nope, you're right, you need to filter at the client side. Cheers, David _______________________________________________ hal mailing list hal@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/hal