From david at fubar.dk Mon Nov 2 10:58:32 2009 From: david at fubar.dk (David Zeuthen) Date: Mon, 02 Nov 2009 13:58:32 -0500 Subject: [PATCH] param. names In-Reply-To: <4a911d493a32883abcf8073cfaf690cb.squirrel@mail.uninstall.it> References: <4a911d493a32883abcf8073cfaf690cb.squirrel@mail.uninstall.it> Message-ID: <1257188312.20010.7.camel@localhost.localdomain> On Mon, 2009-09-21 at 16:56 +0200, Davide Bettio wrote: > Hi, > > This patch[1] fixes some issues with qdbusxml2cpp (that may generate > broken code). Hey, sorry for the delay. I've committed something like this. Please use bugzilla, here https://bugs.freedesktop.org/enter_bug.cgi?product=DeviceKit-disks in the future for patches and bug reports - otherwise I end up forgetting about it! Thanks, David From david at fubar.dk Mon Nov 2 13:25:54 2009 From: david at fubar.dk (David Zeuthen) Date: Mon, 02 Nov 2009 16:25:54 -0500 Subject: DeviceKit-disks 009 Message-ID: <1257197154.20010.31.camel@localhost.localdomain> Hey, Here's a release of DKD 009, mostly bug-fixes compared to 008. http://hal.freedesktop.org/releases/DeviceKit-disks-009.tar.gz ------------------- DeviceKit-disks 009 ------------------- DeviceKit-disks is a daemon that provide interfaces to obtain information and perform operations on storage devices. NOTE NOTE NOTE: This is an unstable release of DeviceKit-disks, all API is subject to change. David Zeuthen (15): Post-release version bump to 009 Various device-mapper and cryptsetup fixes Pass -T to cryptsetup to handle incorrect passphrases When updating holders/slaves, defer the updates to an idle handler Work around blkid incorrectly detecting FAT on extended partitions Use 'udevadm settle' instead of 15-second timeout Allow creating a partition table with same scheme as existing one Pass -F to mkfs.ext[234] to allow creating a filesystem on the whole disk Use unregister facility in dbus-glib 0.82 and misc life-cycle fixes Add new LinuxMdComponentPosition property Also ignore a device if DM_UDEV_DISABLE_OTHER_RULES_FLAG is set Use BLKPG_DEL_PARTITION when deleting partitions instead of libparted Use BLKPG_ADD_PARTITION when adding a partition Don't use hyphens in param names Update NEWS for release Martin Pitt (6): Bug 24673 ? Support creating swap fs with labels Bug 24778 ? throw_error() segfaults for daemon-internally called methods Bug 24757 ? Bashism in luks helper breaks password changing Bug 24757 ? Simplify helper-change-luks-password Bug 24679 ? Support creating minix file systems Bug 24718 ? Proper handling of missing mkfs.*/fsck.* David Zeuthen, November 2, 2009 From daniel at admin-box.com Mon Nov 2 14:43:20 2009 From: daniel at admin-box.com (Daniel Troeder) Date: Mon, 02 Nov 2009 23:43:20 +0100 Subject: I want to hibernate on encrypted swap space Message-ID: <1257201800.19483.96.camel@maya.local> Hello :) I have an encrypted root and swap in an encrypted LVM-VG, which I "decrypt" (luksOpen) with my initramfs. Pretty standard setup with Debian and Ubuntu when using encryption btw. (though I'm using Gentoo :) So it is perfectly OK for me to hibernate to my swap, because I can also restore from it. $ dbus-send --system --dest=org.freedesktop.DeviceKit.Power --type=method_call --print-reply=yes /org/freedesktop/DeviceKit/Power org.freedesktop.DeviceKit.Power.Hibernate Error org.freedesktop.DeviceKit.Power.GeneralError: Swap space is encrypted I was thinking why you do this, and think the problem for devkit-power is, that you cannot know easily how an encrypted swap is used (with fixed key like mine or with random key). So you choose the safe way to disallow it. I don't know of a portable way to check for this. I think people with random key have to set this up in /etc/crypttab (which I don't have). Maybe this can be detected and distinguished from people with fixed key setups? Another idea would be to have the UI (gnome-power-manager?) ask the user for desired behavior. Is this maybe something devkit-disks should find out? (In the meantime I'll live with "$ sudo pm-hibernate" or suspend :) A different matter is, that I cannot hibernate (due to the above), but "can-hibernate" is nevertheless "yes" (in "$ devkit-power -d"). Thus gnome-power-manager gives me the option to choose "hibernate"... Anyway, thanx for all your work :) Bye, Daniel -- PGP key @ http://pgpkeys.pca.dfn.de/pks/lookup?search=0xBB9D4887&op=get # gpg --recv-keys --keyserver hkp://subkeys.pgp.net 0xBB9D4887 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.freedesktop.org/archives/devkit-devel/attachments/20091102/ba88ca04/attachment.pgp From david at fubar.dk Mon Nov 2 15:05:28 2009 From: david at fubar.dk (David Zeuthen) Date: Mon, 02 Nov 2009 18:05:28 -0500 Subject: gnome-disk-utility 2.28.1 Message-ID: <1257203128.2116.2.camel@localhost.localdomain> Hey, Here's also a new gnome-disk-utility release http://hal.freedesktop.org/releases/gnome-disk-utility-2.28.1.tar.bz2 See below for details. Work contains in the new-ui branch which will soon be merged into master Thanks, David ------------------------- gnome-disk-utility 2.28.1 ------------------------- gnome-disk-utility provides libraries and applications for dealing with storage devices. NOTE NOTE NOTE: This release is API and ABI compatible only with other releases in the 2.28.x series. David Zeuthen (3): Bump version to 2.28.1 Turn some warnings that are not fatal into debug messages Update NEWS for release Matthias Clasen (5): Use stock delete and apply buttons Fix library translations Use translated string for button label Translate file system types Forgotten string Tomas Bzatek (2): Nautilus extension: ref and unref objects correctly Don't crash when presentable has no device Updated translations: A S Alam (pa) Alexander Shopov (bg) Andrej ?nidar?i? (sl) Andr? Gondim (pt_BR) Christian Kirbach (de) Claude Paroz (fr) Daniel Nylander (sv) Gabor Kelemen (hu) Gil Forcadah (ca) Gintautas Miliauskas (lt) Jorge Gonz?lez (es) Kjartan Maraas (nb) Leonid Kanter (ru) Manoj Kumar Giri (or) Marek ?ernock? (cz) Matej Urban?i? (sl) Mattias P?ldaru (et) Milo Casagrande (it) Shankar Prasad (kn) Tournaris Pavlos (el) ?ygimantas Beru?ka (lt) David Zeuthen, November 2, 2009 From hughsient at gmail.com Mon Nov 2 16:36:19 2009 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 3 Nov 2009 00:36:19 +0000 Subject: I want to hibernate on encrypted swap space In-Reply-To: <1257201800.19483.96.camel@maya.local> References: <1257201800.19483.96.camel@maya.local> Message-ID: <15e53e180911021636v6c8adfb2g45b3a5883e4c6cd9@mail.gmail.com> 2009/11/2 Daniel Troeder : > $ dbus-send --system --dest=org.freedesktop.DeviceKit.Power --type=method_call --print-reply=yes /org/freedesktop/DeviceKit/Power org.freedesktop.DeviceKit.Power.Hibernate > Error org.freedesktop.DeviceKit.Power.GeneralError: Swap space is encrypted Better logic is probably needed in DeviceKit-power. Patches or ideas welcome. Richard. From martin.pitt at ubuntu.com Thu Nov 5 15:41:30 2009 From: martin.pitt at ubuntu.com (Martin Pitt) Date: Fri, 6 Nov 2009 00:41:30 +0100 Subject: devkit segfaults in do_show_info() In-Reply-To: <20091008020257.GB30569@b1b1.lan> References: <20090929182035.GA20661@b1b1.lan> <20091001112256.GA13502@b1b1.lan> <20091005221836.GA27650@b1b1.lan> <20091008020257.GB30569@b1b1.lan> Message-ID: <20091105234130.GX2428@piware.de> gibboris at gmail.com [2009-10-08 4:02 +0200]: > Resolved the 'introspection data references non-existing property' > by updating dbus-glib from 0.76 to 0.80, it should *really* be > noted in the README for the ease of maintainers and the > ./configure should *really* check it. FYI, current DK-D requries dbus-glib 0.82, so I think this is settled now? Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) From gibboris at gmail.com Thu Nov 5 16:19:53 2009 From: gibboris at gmail.com (gibboris at gmail.com) Date: Fri, 6 Nov 2009 01:19:53 +0100 Subject: devkit segfaults in do_show_info() In-Reply-To: <20091105234130.GX2428@piware.de> References: <20090929182035.GA20661@b1b1.lan> <20091001112256.GA13502@b1b1.lan> <20091005221836.GA27650@b1b1.lan> <20091008020257.GB30569@b1b1.lan> <20091105234130.GX2428@piware.de> Message-ID: <20091106001953.GC23479@b1b1.lan> On Fri, Nov 06, 2009 at 12:41:30AM +0100, Martin Pitt wrote: > gibboris at gmail.com [2009-10-08 4:02 +0200]: > > Resolved the 'introspection data references non-existing property' > > by updating dbus-glib from 0.76 to 0.80, it should *really* be > > noted in the README for the ease of maintainers and the > > ./configure should *really* check it. > > FYI, current DK-D requries dbus-glib 0.82, so I think this is settled > now? here it is, now (sry for noise) but wasn't the case everywhere (http://bugs.gentoo.org/show_bug.cgi?id=291168, if reproducable) > > Martin > -- > Martin Pitt | http://www.piware.de > Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) From topfs2 at xboxmediacenter.com Fri Nov 6 01:17:09 2009 From: topfs2 at xboxmediacenter.com (Tobias Arrskog) Date: Fri, 6 Nov 2009 10:17:09 +0100 Subject: [PATCH] OnResume, OnHibernate and OnSuspend signals. Message-ID: <83d38be90911060117r3773db92m149844c61ceac6f6@mail.gmail.com> Hi I'm one of the developers off XBMC and we have found that we have a need to get OnSuspend, OnResume events. For us it's mainly to trigger rescans of files and reset sockets to LIRC but if we need it, other apps might too. So I made a pm-util script which will expand the signal in DeviceKit.Power to contain OnResume, OnHibernate, OnSuspend. I'm not sure if I should paste this here or over at pm-utils? both are freedesktop so perhaps there is some interconnection? Perhaps DeviceKit.Power have some better implementation ideas for this? P.S I'm not sure on the numbering before the script so I have omitted them for now. /Tobias Arrskog a.k.a topfs2 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freedesktop.org/archives/devkit-devel/attachments/20091106/0291be9d/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: DeviceKitPower Type: application/octet-stream Size: 569 bytes Desc: not available Url : http://lists.freedesktop.org/archives/devkit-devel/attachments/20091106/0291be9d/attachment.obj From jasonlife.work at gmail.com Fri Nov 6 08:58:11 2009 From: jasonlife.work at gmail.com (Jason Kim) Date: Fri, 6 Nov 2009 09:58:11 -0700 Subject: DeviceKit-Disks and multiseat Message-ID: <579044190911060858ka2f335dj19f7f3e258155fb0@mail.gmail.com> I'm playing with multiseat configuration, and i'm wondering if there is a way to allow mounting a disk only to a specific seat if there are multiple active sessions. I have tried different things, but couldn't find a way yet. Every active sessions can mount disks. Is it possible to check "Seat id" or "User id" during the DeviceKit-Disks actions ? Or is there a way to launch a external program to authenticate actions? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freedesktop.org/archives/devkit-devel/attachments/20091106/aecf376b/attachment.html From buhitoescolar at gmail.com Fri Nov 6 10:39:25 2009 From: buhitoescolar at gmail.com (=?ISO-8859-1?Q?Emilio_L=F3pez?=) Date: Fri, 6 Nov 2009 15:39:25 -0300 Subject: DevKit-Power doesn't detect the system is running on battery power if you boot your laptop without AC power Message-ID: Hello, I wasn't able to find any bug tracker for DevKit, that is why I'm writing here. I'm experiencing a problem with DevKit-Power and gnome-power-manager: if you boot a laptop using its battery (no AC cable plugged in), gnome-power-manager reports it's running on AC power, and says there is no battery. Running "devkit-power -d", it reveals it's not gnome-power-manager's fault, as devkit doesn't detect the battery and says it's running on AC power. I'm using devkit-power 011 on Ubuntu Karmic Koala, and my PC is an Acer Aspire 6930. Given that I don't know what should be done to debug this, I would appreciate it if you could tell me what to do, or point me to relevant documentation that explains how to debug devkit-power. Do not hesitate to ask if you need further details on the issue. Looking forward to hearing from you, -- Emilio L?pez -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freedesktop.org/archives/devkit-devel/attachments/20091106/ba435584/attachment.html From maximlevitsky at gmail.com Sun Nov 8 15:20:44 2009 From: maximlevitsky at gmail.com (Maxim Levitsky) Date: Mon, 09 Nov 2009 01:20:44 +0200 Subject: How to suspend/hibernate remote system without root Message-ID: <1257722444.5552.3.camel@maxim-laptop> I need to suspend/hibernate remote system, and I currently use an ugly sudo without passwork hack. Is this possible to do with devicekit? I have tried the dbus-send --print-reply --system --dest=org.freedesktop.DeviceKit.Power /org/freedesktop/DeviceKit/Power org.freedesktop.DeviceKit.Power.Suspend But it fails with 'not authorized' message. Locally it works. Best regards, Maxim Levitky From aliov at xfce.org Sun Nov 8 23:40:07 2009 From: aliov at xfce.org (Ali Abdallah) Date: Mon, 09 Nov 2009 08:40:07 +0100 Subject: How to suspend/hibernate remote system without root In-Reply-To: <1257722444.5552.3.camel@maxim-laptop> References: <1257722444.5552.3.camel@maxim-laptop> Message-ID: <4AF7C757.4090606@xfce.org> Maxim Levitsky wrote: > dbus-send > --print-reply > --system --dest=org.freedesktop.DeviceKit.Power > /org/freedesktop/DeviceKit/Power org.freedesktop.DeviceKit.Power.Suspend > > But it fails with 'not authorized' message. > Locally it works. > > You need to setup polkit authorization for the user to use the Suspend and Hibernate of devkit-power, most probably polkit authorization definitions are in /var/lib/polkit-1/localauthority/ and there should be a folder called 50-local.d, make a file there called org.freedesktop.devicekit.power.pkla and contains something like [Local Users] Identity=unix-user:your_user_name Action=org.freedesktop.devicekit.power.Suspend ResultAny=yes ResultInactive=no ResultActive=yes You can also use Action=org.freedesktop.devicekit.power.* to use both Suspend and Hibernate. for more information have a look to man pklocalauthority > Best regards, > Maxim Levitky > Best Regards, Ali. > > _______________________________________________ > devkit-devel mailing list > devkit-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/devkit-devel > From martin.pitt at ubuntu.com Fri Nov 13 05:30:48 2009 From: martin.pitt at ubuntu.com (Martin Pitt) Date: Fri, 13 Nov 2009 14:30:48 +0100 Subject: Migrating suspend quirks away from hal Message-ID: <20091113133048.GO2501@piware.de> Hello Victor, hello Richard, hello devkitters, in the past half year we have come quite far with the "halsectomy", i.e. deprecating hal [1]. The main two remaining items are now X.org input devices (where a patch is already being discussed), and the suspend quirks in pm-utils. I would like to push this forward a little. From what I can see, the are two sensible options: (1) Convert the hal-info suspend quirks to a simple text format and put it into/maintain it directly in pm-utils. ? nice encapsulation, maintained at the place where they are actually needed (2) Convert the quirks to udev rules shipped by/maintained in dk-power, and pass the quirks to pm-{suspend,hibernate} as command line arguments. ? we would benefit from the existing and efficient vendor/model->properties matching capabilities of udev, but would have to find an artificial device to attach them to (there is no "computer object" in udev, unlike in hal) My personal preference is (1). Victor, Richard, what do you think? I am happy to create some scripts to convert the hal-info data to some text format or udev rules. I have a certain experience with that from converting keymaps [2] and music players [3], after all. :-) Thanks, Martin [1] https://wiki.ubuntu.com/Halsectomy [2] http://lists.freedesktop.org/archives/devkit-devel/2009-May/000171.html [3] http://lists.freedesktop.org/archives/devkit-devel/2009-June/000226.html -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.freedesktop.org/archives/devkit-devel/attachments/20091113/0dcf595c/attachment.pgp From cfergeau at gmail.com Fri Nov 13 05:54:16 2009 From: cfergeau at gmail.com (Christophe Fergeau) Date: Fri, 13 Nov 2009 14:54:16 +0100 Subject: Revert "10-usb-music-players.fdi: Flatten product id tests" In-Reply-To: <20090824061229.GO3711@piware.de> References: <20090824061229.GO3711@piware.de> Message-ID: Hello Danny, I don't think I ever got an answer to my original mail or to the mail below (which you can find in full at http://lists.freedesktop.org/archives/hal/2009-August/013560.html ). Can we go ahead with reflattening this file ? This would let us go forward with media-player-info while keeping hal-info in sync. Thanks, Christophe 2009/8/24 Martin Pitt : > Hello Danny, hello Christophe, > > (keeping fullquote for the list) > > Christophe Fergeau [2009-08-11 14:06 +0200]: >> Hi Danny, >> >> I'm writing you about the revert you did some days ago in hal-info for >> the "Flatten product id tests" commit [1]. We are currently trying to >> move away from HAL, and this commit makes it much easier to convert >> the media player HAL rules to mpi files (media player information >> files) and to keep both set of rules in sync. >> 3kB more data don't strike me as something that would have such an >> impact on HAL performance or disk usage, especially given the current >> size of the file and given that most distros will probably stop >> shipping hal-info (at least this file) soon. >> >> Would you consider reverting this revert? >> >> Thanks, >> >> Christophe >> >> [1] http://cgit.freedesktop.org/hal-info/commit/?id=8a8d78461c45456d89bbb39e47e5d6e366e79486 > > So this doesnt' seem to be unanimous. I originally changed that to > simplify the structure of the hal-info files to make them translatable > to *.mpi files automatically (which becomes an unnecessarily hard > problem with the nesting reintroduced with that revert). > > Since hal will probably stay around for a while (Solaris, BSD), I > think we should strive for keeping the music player data convertible > automatically. Right now I already have to make the keyboard quirks > changes twice (once in hal-info, once in udev). > > Danny, when would you be content with reintroducing the flat > structure? When banshee is using *.mpi files as well? Rhythmbox > already switched over to gudev in 0.12.4. > > Thanks, > > Martin > -- > Martin Pitt ? ? ? ? ? ? ? ? ? ? ? ?| http://www.piware.de > Ubuntu Developer (www.ubuntu.com) ?| Debian Developer ?(www.debian.org) > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkqSL00ACgkQDecnbV4Fd/L5RwCg9yyIh6Wwj6RcDwoRnWQfkYMx > c+oAn199/wBUmRO+FQ+HP9n2Unk8MH92 > =T318 > -----END PGP SIGNATURE----- > > From mjg59 at srcf.ucam.org Fri Nov 13 07:03:51 2009 From: mjg59 at srcf.ucam.org (Matthew Garrett) Date: Fri, 13 Nov 2009 15:03:51 +0000 Subject: Migrating suspend quirks away from hal In-Reply-To: <20091113133048.GO2501@piware.de> References: <20091113133048.GO2501@piware.de> Message-ID: <20091113150351.GA31426@srcf.ucam.org> Bear in mind that with current kernels, resume should work without quirks on all intel and radeon, and will basically never do anything useful on nvidia. These are very much a legacy holdover, and at this point I'd recommend dropping support for them entirely. The market share of everyone else put together is miniscule, and if they're not interested in supporting Linux properly then we shouldn't be carrying piles of ugliness for their benefit. -- Matthew Garrett | mjg59 at srcf.ucam.org From hughsient at gmail.com Fri Nov 13 07:26:25 2009 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 13 Nov 2009 15:26:25 +0000 Subject: Migrating suspend quirks away from hal In-Reply-To: <20091113150351.GA31426@srcf.ucam.org> References: <20091113133048.GO2501@piware.de> <20091113150351.GA31426@srcf.ucam.org> Message-ID: <15e53e180911130726jd10965cl48210d21f5a557b4@mail.gmail.com> 2009/11/13 Matthew Garrett : > useful on nvidia. These are very much a legacy holdover, and at this > point I'd recommend dropping support for them entirely. The market share > of everyone else put together is miniscule, and if they're not > interested in supporting Linux properly then we shouldn't be carrying > piles of ugliness for their benefit. I agree. In a post KMS world quirks are not really useful any more. Richard. From david at fubar.dk Fri Nov 13 07:50:26 2009 From: david at fubar.dk (David Zeuthen) Date: Fri, 13 Nov 2009 10:50:26 -0500 Subject: Migrating suspend quirks away from hal In-Reply-To: <20091113150351.GA31426@srcf.ucam.org> References: <20091113133048.GO2501@piware.de> <20091113150351.GA31426@srcf.ucam.org> Message-ID: <1258127426.7574.5.camel@localhost.localdomain> On Fri, 2009-11-13 at 15:03 +0000, Matthew Garrett wrote: > Bear in mind that with current kernels, resume should work without > quirks on all intel and radeon, and will basically never do anything > useful on nvidia. These are very much a legacy holdover, and at this > point I'd recommend dropping support for them entirely. The market share > of everyone else put together is miniscule, and if they're not > interested in supporting Linux properly then we shouldn't be carrying > piles of ugliness for their benefit. I concur. David From mbiebl at gmail.com Fri Nov 13 08:15:36 2009 From: mbiebl at gmail.com (Michael Biebl) Date: Fri, 13 Nov 2009 17:15:36 +0100 Subject: [Pm-utils] Migrating suspend quirks away from hal In-Reply-To: <20091113150351.GA31426@srcf.ucam.org> References: <20091113133048.GO2501@piware.de> <20091113150351.GA31426@srcf.ucam.org> Message-ID: 2009/11/13 Matthew Garrett : > Bear in mind that with current kernels, resume should work without > quirks on all intel and radeon, and will basically never do anything > useful on nvidia. These are very much a legacy holdover, and at this > point I'd recommend dropping support for them entirely. So, in pm-utils we strip away any quirks for users of the proprietary nvidia and fglrx drivers. And also for any KMS enabled kernel and users of the i915 module (for intel). What is the current status of KMS for radeon and noveau? Is radeon KMS still marked as experimental? What do we do about users of radeon w/o KMS, nv or intel w/o i915? Imo at this point it is a bit premature to rely on KMS only. Of course we can just keep hal around for that purpose a little longer and safe us the effort of a transition. My guess is, that Martin want's to get rid of hal completely for a default GNOME desktop install in Lucid? Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From mjg59 at srcf.ucam.org Fri Nov 13 08:21:11 2009 From: mjg59 at srcf.ucam.org (Matthew Garrett) Date: Fri, 13 Nov 2009 16:21:11 +0000 Subject: [Pm-utils] Migrating suspend quirks away from hal In-Reply-To: References: <20091113133048.GO2501@piware.de> <20091113150351.GA31426@srcf.ucam.org> Message-ID: <20091113162111.GA1023@srcf.ucam.org> On Fri, Nov 13, 2009 at 05:15:36PM +0100, Michael Biebl wrote: > What is the current status of KMS for radeon and noveau? Is radeon KMS > still marked as experimental? It's marked as experimental, but only because the ABI isn't fixed yet. It should work. nouveau KMS works fine, including suspend/resume support on most machines. > What do we do about users of radeon w/o KMS, nv or intel w/o i915? nv is broadly irrelevant (quirks aren't going to help you there), running intel without i915 isn't going to work with the next driver release (which will be before any distribution ships without hal) and radeon without kms is effectively deprecated. > Imo at this point it is a bit premature to rely on KMS only. Of course > we can just keep hal around for that purpose a little longer and safe > us the effort of a transition. My guess is, that Martin want's to get > rid of hal completely for a default GNOME desktop install in Lucid? Given that the X transition away from hal hasn't happened yet, there's no realistic chance of anyone shipping a halless distribution in the next release cycle. And by then KMS should be solid for everything. -- Matthew Garrett | mjg59 at srcf.ucam.org From victor.lowther at gmail.com Fri Nov 13 10:30:18 2009 From: victor.lowther at gmail.com (Victor Lowther) Date: Fri, 13 Nov 2009 12:30:18 -0600 Subject: Migrating suspend quirks away from hal In-Reply-To: <20091113133048.GO2501@piware.de> References: <20091113133048.GO2501@piware.de> Message-ID: <8B748CED-600B-4A5C-BD1C-7D5A2B977F7A@gmail.com> On Nov 13, 2009, at 7:30 AM, Martin Pitt wrote: > Hello Victor, hello Richard, hello devkitters, > > in the past half year we have come quite far with the "halsectomy", > i.e. deprecating hal [1]. The main two remaining items are now X.org > input devices (where a patch is already being discussed), and the > suspend quirks in pm-utils. > > I would like to push this forward a little. From what I can see, the > are two sensible options: > > (1) Convert the hal-info suspend quirks to a simple text format and > put it into/maintain it directly in pm-utils. > > ? nice encapsulation, maintained at the place where they are > actually needed I did this as an experiment last year, and it worked out well at the time. I will see if I still have that branch around somewhere to make available for comment. > (2) Convert the quirks to udev rules shipped by/maintained in > dk-power, and pass the quirks to pm-{suspend,hibernate} as > command line arguments. > > ? we would benefit from the existing and efficient > vendor/model->properties matching capabilities of udev, but would > have to find an artificial device to attach them to (there is no > "computer object" in udev, unlike in hal) > > My personal preference is (1). Victor, Richard, what do you think? > > I am happy to create some scripts to convert the hal-info data to some > text format or udev rules. I have a certain experience with that from > converting keymaps [2] and music players [3], after all. :-) > > Thanks, > > Martin > > [1] https://wiki.ubuntu.com/Halsectomy > [2] http://lists.freedesktop.org/archives/devkit-devel/2009-May/000171.html > [3] http://lists.freedesktop.org/archives/devkit-devel/2009-June/000226.html > > -- > Martin Pitt | http://www.piware.de > Ubuntu Developer (www.ubuntu.com) | Debian Developer > (www.debian.org) From victor.lowther at gmail.com Fri Nov 13 10:35:36 2009 From: victor.lowther at gmail.com (Victor Lowther) Date: Fri, 13 Nov 2009 12:35:36 -0600 Subject: [Pm-utils] Migrating suspend quirks away from hal In-Reply-To: <20091113162111.GA1023@srcf.ucam.org> References: <20091113133048.GO2501@piware.de> <20091113150351.GA31426@srcf.ucam.org> <20091113162111.GA1023@srcf.ucam.org> Message-ID: <1B4734EE-4687-498B-B32C-65C62B57D36C@gmail.com> On Nov 13, 2009, at 10:21 AM, Matthew Garrett wrote: > On Fri, Nov 13, 2009 at 05:15:36PM +0100, Michael Biebl wrote: > >> What is the current status of KMS for radeon and noveau? Is radeon >> KMS >> still marked as experimental? > > It's marked as experimental, but only because the ABI isn't fixed yet. > It should work. nouveau KMS works fine, including suspend/resume > support > on most machines. > >> What do we do about users of radeon w/o KMS, nv or intel w/o i915? > > nv is broadly irrelevant (quirks aren't going to help you there), > running intel without i915 isn't going to work with the next driver > release (which will be before any distribution ships without hal) and > radeon without kms is effectively deprecated. You are writing off a lot of legacy hardware that is probably still in use, as well as everything that is not intel, radeon, or nvidia. The quirks database should stay in some form. >> Imo at this point it is a bit premature to rely on KMS only. Of >> course >> we can just keep hal around for that purpose a little longer and safe >> us the effort of a transition. My guess is, that Martin want's to get >> rid of hal completely for a default GNOME desktop install in Lucid? > > Given that the X transition away from hal hasn't happened yet, there's > no realistic chance of anyone shipping a halless distribution in the > next release cycle. And by then KMS should be solid for everything. Even sis, tseng, matrox, and all the smaller players? > -- > Matthew Garrett | mjg59 at srcf.ucam.org > _______________________________________________ > Pm-utils mailing list > Pm-utils at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/pm-utils From mjg59 at srcf.ucam.org Fri Nov 13 10:42:23 2009 From: mjg59 at srcf.ucam.org (Matthew Garrett) Date: Fri, 13 Nov 2009 18:42:23 +0000 Subject: [Pm-utils] Migrating suspend quirks away from hal In-Reply-To: <1B4734EE-4687-498B-B32C-65C62B57D36C@gmail.com> References: <20091113133048.GO2501@piware.de> <20091113150351.GA31426@srcf.ucam.org> <20091113162111.GA1023@srcf.ucam.org> <1B4734EE-4687-498B-B32C-65C62B57D36C@gmail.com> Message-ID: <20091113184223.GA3872@srcf.ucam.org> On Fri, Nov 13, 2009 at 12:35:36PM -0600, Victor Lowther wrote: > You are writing off a lot of legacy hardware that is probably still in > use, as well as everything that is not intel, radeon, or nvidia. The > quirks database should stay in some form. I don't see how legacy hardware fits into this - hal's not going anywhere on current distribution releases. >> Given that the X transition away from hal hasn't happened yet, there's >> no realistic chance of anyone shipping a halless distribution in the >> next release cycle. And by then KMS should be solid for everything. > > Even sis, tseng, matrox, and all the smaller players? The quirk setup makes no sense for desktop hardware. In the mobile market, the only other GPU I've seen in anything vaguely modern has been VIA - and to pretend that their hardware is supported by Linux at all at the moment is just a good way of misleading our users. -- Matthew Garrett | mjg59 at srcf.ucam.org From victor.lowther at gmail.com Fri Nov 13 18:42:20 2009 From: victor.lowther at gmail.com (Victor Lowther) Date: Fri, 13 Nov 2009 20:42:20 -0600 Subject: Migrating suspend quirks away from hal In-Reply-To: <8B748CED-600B-4A5C-BD1C-7D5A2B977F7A@gmail.com> References: <20091113133048.GO2501@piware.de> <8B748CED-600B-4A5C-BD1C-7D5A2B977F7A@gmail.com> Message-ID: <1258166540.6283.37.camel@studio> On Fri, 2009-11-13 at 12:30 -0600, Victor Lowther wrote: > On Nov 13, 2009, at 7:30 AM, Martin Pitt wrote: > > > Hello Victor, hello Richard, hello devkitters, > > > > in the past half year we have come quite far with the "halsectomy", > > i.e. deprecating hal [1]. The main two remaining items are now X.org > > input devices (where a patch is already being discussed), and the > > suspend quirks in pm-utils. > > > > I would like to push this forward a little. From what I can see, the > > are two sensible options: > > > > (1) Convert the hal-info suspend quirks to a simple text format and > > put it into/maintain it directly in pm-utils. > > > > ? nice encapsulation, maintained at the place where they are > > actually needed > > I did this as an experiment last year, and it worked out well at the > time. I will see if I still have that branch around somewhere to make > available for comment. Attached is the code I posted to the hal mailing list last November to migrate the video quirk database out of HAL and into something a little easier for bash to deal with. It did not have the full expressive power of the hal-info XML format, but that was mostly not needed anyways -- the only place it was used was the 21-nvidia quirk for handling g80 chipsets with the nv driver, but that can just as easily be hacked into a few lines of bash. Hacking this into a pm-utils hook would not be that tricky -- the flow would go something like this: if has_kms || has_nvidia || has_fglrx || has_smart_intel; then skip_all_quirks elif has_nvidia_g80; then do_g80_magic else use_video_quirks fi video_quirks definitly has bugs, but it did OK as a proof of concept for me. -------------- next part -------------- A non-text attachment was scrubbed... Name: video-quirks.bash Type: application/x-shellscript Size: 10898 bytes Desc: not available Url : http://lists.freedesktop.org/archives/devkit-devel/attachments/20091113/f51f9b34/attachment.bin From victor.lowther at gmail.com Sun Nov 15 19:59:15 2009 From: victor.lowther at gmail.com (Victor Lowther) Date: Sun, 15 Nov 2009 21:59:15 -0600 Subject: Migrating suspend quirks away from hal In-Reply-To: <1258166540.6283.37.camel@studio> References: <20091113133048.GO2501@piware.de> <8B748CED-600B-4A5C-BD1C-7D5A2B977F7A@gmail.com> <1258166540.6283.37.camel@studio> Message-ID: <1258343955.6283.45.camel@studio> On Fri, 2009-11-13 at 20:42 -0600, Victor Lowther wrote: > On Fri, 2009-11-13 at 12:30 -0600, Victor Lowther wrote: > > On Nov 13, 2009, at 7:30 AM, Martin Pitt wrote: > > > > > Hello Victor, hello Richard, hello devkitters, > > > > > > in the past half year we have come quite far with the "halsectomy", > > > i.e. deprecating hal [1]. The main two remaining items are now X.org > > > input devices (where a patch is already being discussed), and the > > > suspend quirks in pm-utils. > > > > > > I would like to push this forward a little. From what I can see, the > > > are two sensible options: > > > > > > (1) Convert the hal-info suspend quirks to a simple text format and > > > put it into/maintain it directly in pm-utils. > > > > > > ? nice encapsulation, maintained at the place where they are > > > actually needed > > > > I did this as an experiment last year, and it worked out well at the > > time. I will see if I still have that branch around somewhere to make > > available for comment. > > Attached is the code I posted to the hal mailing list last November to > migrate the video quirk database out of HAL and into something a little > easier for bash to deal with. It did not have the full expressive power > of the hal-info XML format, but that was mostly not needed anyways -- > the only place it was used was the 21-nvidia quirk for handling g80 > chipsets with the nv driver, but that can just as easily be hacked into > a few lines of bash. And now, a version that actaully works. With a bit of glue code, this can replace auto quirk and smart kernel driver handling in pm-utils. Yes, I know that I am insane for parsing XML in bash. In my defense, I only do it when I have to. The sooner we no longer rely on .fdi files, the better. Comments, flames (except XML-related ones and ones implying we no longer have to worry about quirks), etc. welcome. > Hacking this into a pm-utils hook would not be that tricky -- the flow > would go something like this: > > if has_kms || has_nvidia || has_fglrx || has_smart_intel; then > skip_all_quirks > elif has_nvidia_g80; then > do_g80_magic > else > use_video_quirks > fi > > video_quirks definitly has bugs, but it did OK as a proof of concept for > me. From victor.lowther at gmail.com Sun Nov 15 20:01:18 2009 From: victor.lowther at gmail.com (Victor Lowther) Date: Sun, 15 Nov 2009 22:01:18 -0600 Subject: Migrating suspend quirks away from hal In-Reply-To: <1258343955.6283.45.camel@studio> References: <20091113133048.GO2501@piware.de> <8B748CED-600B-4A5C-BD1C-7D5A2B977F7A@gmail.com> <1258166540.6283.37.camel@studio> <1258343955.6283.45.camel@studio> Message-ID: <1258344078.6283.46.camel@studio> On Sun, 2009-11-15 at 21:59 -0600, Victor Lowther wrote: > On Fri, 2009-11-13 at 20:42 -0600, Victor Lowther wrote: > > On Fri, 2009-11-13 at 12:30 -0600, Victor Lowther wrote: > > > On Nov 13, 2009, at 7:30 AM, Martin Pitt wrote: > > > > > > > Hello Victor, hello Richard, hello devkitters, > > > > > > > > in the past half year we have come quite far with the "halsectomy", > > > > i.e. deprecating hal [1]. The main two remaining items are now X.org > > > > input devices (where a patch is already being discussed), and the > > > > suspend quirks in pm-utils. > > > > > > > > I would like to push this forward a little. From what I can see, the > > > > are two sensible options: > > > > > > > > (1) Convert the hal-info suspend quirks to a simple text format and > > > > put it into/maintain it directly in pm-utils. > > > > > > > > ? nice encapsulation, maintained at the place where they are > > > > actually needed > > > > > > I did this as an experiment last year, and it worked out well at the > > > time. I will see if I still have that branch around somewhere to make > > > available for comment. > > > > Attached is the code I posted to the hal mailing list last November to > > migrate the video quirk database out of HAL and into something a little > > easier for bash to deal with. It did not have the full expressive power > > of the hal-info XML format, but that was mostly not needed anyways -- > > the only place it was used was the 21-nvidia quirk for handling g80 > > chipsets with the nv driver, but that can just as easily be hacked into > > a few lines of bash. > > And now, a version that actaully works. With a bit of glue code, this > can replace auto quirk and smart kernel driver handling in pm-utils. Now with actual file! > Yes, I know that I am insane for parsing XML in bash. In my defense, I > only do it when I have to. The sooner we no longer rely on .fdi files, > the better. > > Comments, flames (except XML-related ones and ones implying we no longer > have to worry about quirks), etc. welcome. > > > Hacking this into a pm-utils hook would not be that tricky -- the flow > > would go something like this: > > > > if has_kms || has_nvidia || has_fglrx || has_smart_intel; then > > skip_all_quirks > > elif has_nvidia_g80; then > > do_g80_magic > > else > > use_video_quirks > > fi > > > > video_quirks definitly has bugs, but it did OK as a proof of concept for > > me. > -------------- next part -------------- A non-text attachment was scrubbed... Name: video-quirks.bash Type: application/x-shellscript Size: 16321 bytes Desc: not available Url : http://lists.freedesktop.org/archives/devkit-devel/attachments/20091115/558ab24e/attachment-0001.bin From hughsient at gmail.com Tue Nov 17 04:25:12 2009 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 17 Nov 2009 12:25:12 +0000 Subject: DevKit-Power doesn't detect the system is running on battery power if you boot your laptop without AC power In-Reply-To: References: Message-ID: <15e53e180911170425w7f98e647j53a7970f05a0ec47@mail.gmail.com> 2009/11/6 Emilio L?pez : > Running "devkit-power -d", it reveals it's not > gnome-power-manager's fault, as devkit doesn't detect the battery and says > it's running on AC power. I'm using devkit-power 011 on Ubuntu Karmic Koala, > and my PC is an Acer Aspire 6930. Do you have any battery devices in /sys/class/power_supply? Richard. From buhitoescolar at gmail.com Tue Nov 17 10:16:31 2009 From: buhitoescolar at gmail.com (=?ISO-8859-1?Q?Emilio_L=F3pez?=) Date: Tue, 17 Nov 2009 15:16:31 -0300 Subject: DevKit-Power doesn't detect the system is running on battery power if you boot your laptop without AC power In-Reply-To: <15e53e180911170425w7f98e647j53a7970f05a0ec47@mail.gmail.com> References: <15e53e180911170425w7f98e647j53a7970f05a0ec47@mail.gmail.com> Message-ID: Hello, 2009/11/17 Richard Hughes : > 2009/11/6 Emilio L?pez : >> Running "devkit-power -d", it reveals it's not >> gnome-power-manager's fault, as devkit doesn't detect the battery and says >> it's running on AC power. I'm using devkit-power 011 on Ubuntu Karmic Koala, >> and my PC is an Acer Aspire 6930. > > Do you have any battery devices in /sys/class/power_supply? emilio at laptop:~$ ls /sys/class/power_supply ACAD It doesn't seem so. But I have noticed that conky made it work, who knows why. So I disabled conky, restarted, and the problem was there again. So, if devkit-power doesn't see my, and then I do this, emilio at laptop:~$ cat /proc/acpi/battery/BAT1/state present: yes capacity state: ok charging state: discharging present rate: 2056 mA remaining capacity: 1956 mAh present voltage: 10699 mV The battery magically appears, and all the actions get triggered (like lowering screen brightness). emilio at laptop:~$ ls /sys/class/power_supply ACAD BAT1 It seems that cheching that /proc/acpi/battery/BAT1/state makes devkit-power aware of the battery. Any thoughts? Emilio From hughsient at gmail.com Tue Nov 17 14:16:33 2009 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 17 Nov 2009 22:16:33 +0000 Subject: DevKit-Power doesn't detect the system is running on battery power if you boot your laptop without AC power In-Reply-To: References: <15e53e180911170425w7f98e647j53a7970f05a0ec47@mail.gmail.com> Message-ID: <15e53e180911171416l3f6afc1dk376bf920a915b293@mail.gmail.com> 2009/11/17 Emilio L?pez : > emilio at laptop:~$ ls /sys/class/power_supply > ACAD There's the problem. > emilio at laptop:~$ cat /proc/acpi/battery/BAT1/state > present: ? ? ? ? ? ? ? ? yes > capacity state: ? ? ? ? ?ok > charging state: ? ? ? ? ?discharging > present rate: ? ? ? ? ? ?2056 mA > remaining capacity: ? ? ?1956 mAh > present voltage: ? ? ? ? 10699 mV > > The battery magically appears, and all the actions get triggered (like > lowering screen brightness). > > emilio at laptop:~$ ls /sys/class/power_supply > ACAD ?BAT1 That's insane. Your battery driver is broken. > It seems that cheching that /proc/acpi/battery/BAT1/state makes > devkit-power aware of the battery. Any thoughts? Are you using a custom kernel battery driver? Is the source available? Richard From buhitoescolar at gmail.com Tue Nov 17 16:26:31 2009 From: buhitoescolar at gmail.com (=?ISO-8859-1?Q?Emilio_L=F3pez?=) Date: Tue, 17 Nov 2009 21:26:31 -0300 Subject: DevKit-Power doesn't detect the system is running on battery power if you boot your laptop without AC power In-Reply-To: <15e53e180911171416l3f6afc1dk376bf920a915b293@mail.gmail.com> References: <15e53e180911170425w7f98e647j53a7970f05a0ec47@mail.gmail.com> <15e53e180911171416l3f6afc1dk376bf920a915b293@mail.gmail.com> Message-ID: 2009/11/17 Richard Hughes : > 2009/11/17 Emilio L?pez : >> emilio at laptop:~$ ls /sys/class/power_supply >> ACAD > > There's the problem. > >> emilio at laptop:~$ cat /proc/acpi/battery/BAT1/state >> present: ? ? ? ? ? ? ? ? yes >> capacity state: ? ? ? ? ?ok >> charging state: ? ? ? ? ?discharging >> present rate: ? ? ? ? ? ?2056 mA >> remaining capacity: ? ? ?1956 mAh >> present voltage: ? ? ? ? 10699 mV >> >> The battery magically appears, and all the actions get triggered (like >> lowering screen brightness). >> >> emilio at laptop:~$ ls /sys/class/power_supply >> ACAD ?BAT1 > > That's insane. Your battery driver is broken. > >> It seems that cheching that /proc/acpi/battery/BAT1/state makes >> devkit-power aware of the battery. Any thoughts? > > Are you using a custom kernel battery driver? Is the source available? I am using Ubuntu Karmic Koala without any special modules. Here is a lsmod of my PC, the only think that might be PC-specific is acer_wmi, as my PC is an Acer Aspire 6930, but I don't know if this module does something on non-acer PCs. I didn't install it myself, it came with the distro. Here is some information about it: http://www.kernel.org/doc/Documentation/laptops/acer-wmi.txt Module Size Used by binfmt_misc 10220 1 ppdev 8232 0 vboxnetadp 6528 0 vboxnetflt 14288 0 vboxdrv 1777804 2 vboxnetadp,vboxnetflt joydev 13088 0 snd_hda_codec_intelhdmi 14880 1 snd_hda_codec_realtek 277860 1 arc4 2144 2 ecb 3296 2 iwlagn 124768 0 iwlcore 134820 1 iwlagn mac80211 243360 2 iwlagn,iwlcore snd_hda_intel 31880 4 snd_hda_codec 87584 3 snd_hda_codec_intelhdmi,snd_hda_codec_realtek,snd_hda_intel snd_hwdep 9352 1 snd_hda_codec snd_pcm_oss 44704 0 snd_mixer_oss 18976 1 snd_pcm_oss snd_pcm 93160 4 snd_hda_intel,snd_hda_codec,snd_pcm_oss coretemp 7072 0 snd_seq_dummy 3460 0 snd_seq_oss 33440 0 snd_seq_midi 8192 0 uvcvideo 65260 0 snd_rawmidi 27360 1 snd_seq_midi videodev 43360 1 uvcvideo v4l1_compat 16804 2 uvcvideo,videodev v4l2_compat_ioctl32 13344 1 videodev snd_seq_midi_event 8448 2 snd_seq_oss,snd_seq_midi acer_wmi 18504 0 led_class 5256 2 iwlcore,acer_wmi snd_seq 60608 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event snd_timer 26992 2 snd_pcm,snd_seq iptable_filter 3872 0 snd_seq_device 8308 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq ip_tables 21200 1 iptable_filter x_tables 25832 1 ip_tables psmouse 57124 0 serio_raw 6596 0 cfg80211 152424 3 iwlagn,iwlcore,mac80211 lp 11908 0 parport 40528 2 ppdev,lp snd 77096 20 snd_hda_codec_intelhdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device soundcore 9088 1 snd snd_page_alloc 10928 2 snd_hda_intel,snd_pcm dm_raid45 78504 0 xor 5456 1 dm_raid45 fbcon 41344 72 tileblit 3136 1 fbcon font 8832 1 fbcon bitblit 6688 1 fbcon softcursor 2336 1 bitblit i915 246984 3 drm 193856 3 i915 i2c_algo_bit 7076 1 i915 usbhid 43968 0 atl1e 37780 0 usb_storage 65984 0 video 23612 1 i915 output 3680 1 video intel_agp 32816 2 i915 > > Richard > If you need any other information, do not hesitate to request it. Emilio From aquette.dev at gmail.com Fri Nov 20 00:55:29 2009 From: aquette.dev at gmail.com (Arnaud Quette) Date: Fri, 20 Nov 2009 09:55:29 +0100 Subject: DeviceKit-power: USB/HID UPS rules update In-Reply-To: References: Message-ID: Hi Richard and the list, here is another patch for DeviceKit-power, that update the USB/HID UPS rules file against the latest NUT DB [1]. there are 9 new entries, including most notably all the new Dell UPS range, upon their request ;-) cheers, Arnaud -- [1] http://svn.debian.org/wsvn/nut/trunk/scripts/dkp/95-devkit-power-hid.rules -- Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr/ -------------- next part -------------- diff --git a/rules/95-devkit-power-hid.rules b/rules/95-devkit-power-hid.rules index a450fc4..ebff144 100644 --- a/rules/95-devkit-power-hid.rules +++ b/rules/95-devkit-power-hid.rules @@ -14,11 +14,14 @@ ENV{DEVTYPE}=="usb_interface", GOTO="dkp_hid_end" ATTRS{idVendor}=="03f0", ENV{DKP_VENDOR}="Hewlett Packard" ATTRS{idVendor}=="0463", ENV{DKP_VENDOR}="Eaton" +ATTRS{idVendor}=="047c", ENV{DKP_VENDOR}="Dell" ATTRS{idVendor}=="050d", ENV{DKP_VENDOR}="Belkin" ATTRS{idVendor}=="051d", ENV{DKP_VENDOR}="APC" ATTRS{idVendor}=="06da", ENV{DKP_VENDOR}="Liebert" ATTRS{idVendor}=="0764", ENV{DKP_VENDOR}="Cyber Power Systems" ATTRS{idVendor}=="09ae", ENV{DKP_VENDOR}="TrippLite" +ATTRS{idVendor}=="0d9f", ENV{DKP_VENDOR}="PowerCOM" +ATTRS{idVendor}=="10af", ENV{DKP_VENDOR}="Liebert" # Hewlett Packard ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="1f06", ENV{DKP_BATTERY_TYPE}="ups" @@ -28,6 +31,9 @@ ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="1f0a", ENV{DKP_BATTERY_TYPE}="ups" ATTRS{idVendor}=="0463", ATTRS{idProduct}=="0001", ENV{DKP_BATTERY_TYPE}="ups" ATTRS{idVendor}=="0463", ATTRS{idProduct}=="ffff", ENV{DKP_BATTERY_TYPE}="ups" +# Dell +ATTRS{idVendor}=="047c", ATTRS{idProduct}=="ffff", ENV{DKP_BATTERY_TYPE}="ups" + # Belkin ATTRS{idVendor}=="050d", ATTRS{idProduct}=="0375", ENV{DKP_BATTERY_TYPE}="ups" ATTRS{idVendor}=="050d", ATTRS{idProduct}=="0551", ENV{DKP_BATTERY_TYPE}="ups" @@ -48,10 +54,12 @@ ATTRS{idVendor}=="06da", ATTRS{idProduct}=="ffff", ENV{DKP_BATTERY_TYPE}="ups" # Cyber Power Systems ATTRS{idVendor}=="0764", ATTRS{idProduct}=="0005", ENV{DKP_BATTERY_TYPE}="ups" ATTRS{idVendor}=="0764", ATTRS{idProduct}=="0501", ENV{DKP_BATTERY_TYPE}="ups" +ATTRS{idVendor}=="0764", ATTRS{idProduct}=="0601", ENV{DKP_BATTERY_TYPE}="ups" # TrippLite ATTRS{idVendor}=="09ae", ATTRS{idProduct}=="1003", ENV{DKP_BATTERY_TYPE}="ups" ATTRS{idVendor}=="09ae", ATTRS{idProduct}=="1007", ENV{DKP_BATTERY_TYPE}="ups" +ATTRS{idVendor}=="09ae", ATTRS{idProduct}=="1008", ENV{DKP_BATTERY_TYPE}="ups" ATTRS{idVendor}=="09ae", ATTRS{idProduct}=="2005", ENV{DKP_BATTERY_TYPE}="ups" ATTRS{idVendor}=="09ae", ATTRS{idProduct}=="2007", ENV{DKP_BATTERY_TYPE}="ups" ATTRS{idVendor}=="09ae", ATTRS{idProduct}=="3012", ENV{DKP_BATTERY_TYPE}="ups" @@ -60,4 +68,14 @@ ATTRS{idVendor}=="09ae", ATTRS{idProduct}=="4001", ENV{DKP_BATTERY_TYPE}="ups" ATTRS{idVendor}=="09ae", ATTRS{idProduct}=="4002", ENV{DKP_BATTERY_TYPE}="ups" ATTRS{idVendor}=="09ae", ATTRS{idProduct}=="4003", ENV{DKP_BATTERY_TYPE}="ups" +# PowerCOM +ATTRS{idVendor}=="0d9f", ATTRS{idProduct}=="00a2", ENV{DKP_BATTERY_TYPE}="ups" +ATTRS{idVendor}=="0d9f", ATTRS{idProduct}=="00a3", ENV{DKP_BATTERY_TYPE}="ups" +ATTRS{idVendor}=="0d9f", ATTRS{idProduct}=="00a4", ENV{DKP_BATTERY_TYPE}="ups" +ATTRS{idVendor}=="0d9f", ATTRS{idProduct}=="00a5", ENV{DKP_BATTERY_TYPE}="ups" +ATTRS{idVendor}=="0d9f", ATTRS{idProduct}=="00a6", ENV{DKP_BATTERY_TYPE}="ups" + +# Liebert +ATTRS{idVendor}=="10af", ATTRS{idProduct}=="0001", ENV{DKP_BATTERY_TYPE}="ups" + LABEL="dkp_hid_end" From martin.pitt at ubuntu.com Wed Nov 25 04:10:00 2009 From: martin.pitt at ubuntu.com (Martin Pitt) Date: Wed, 25 Nov 2009 13:10:00 +0100 Subject: Migrating suspend quirks away from hal In-Reply-To: <1258343955.6283.45.camel@studio> References: <20091113133048.GO2501@piware.de> <8B748CED-600B-4A5C-BD1C-7D5A2B977F7A@gmail.com> <1258166540.6283.37.camel@studio> <1258343955.6283.45.camel@studio> Message-ID: <20091125121000.GF2416@piware.de> Hello Victor, sorry for the late response; conference and all that.. Victor Lowther [2009-11-15 21:59 -0600]: > And now, a version that actaully works. With a bit of glue code, this > can replace auto quirk and smart kernel driver handling in pm-utils. I just tried your script, but AFAIK it just figures out the quirks that are necessary on the _current_ system by parsing the .fdi directly, right? What I actually had in mind was that we should do a static conversion to produce a simple-to-parse text file map which can then be put into, and maintained within (well, it's not going to change often any more), pm-utils itself, so that we can get rid of hal/hal-info completely. Would you want to change your script accordingly, or want me to work on such a static conversion script? I thought about having one file per vendor, such as /usr/share/pm-utils/video-quirks/ibm and each file would have a list of (dmi property:value)* ? quirks map like product_name:.*X31;bios-version:INET17WW s3_bios s3_mode which can then be matched against /sys/class/dmi/id/* with grep. Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.freedesktop.org/archives/devkit-devel/attachments/20091125/43f48a85/attachment.pgp From victor.lowther at gmail.com Wed Nov 25 06:43:34 2009 From: victor.lowther at gmail.com (Victor Lowther) Date: Wed, 25 Nov 2009 08:43:34 -0600 Subject: Migrating suspend quirks away from hal In-Reply-To: <20091125121000.GF2416@piware.de> References: <20091113133048.GO2501@piware.de> <8B748CED-600B-4A5C-BD1C-7D5A2B977F7A@gmail.com> <1258166540.6283.37.camel@studio> <1258343955.6283.45.camel@studio> <20091125121000.GF2416@piware.de> Message-ID: <921e043f0911250643s3e4baa55g41c3dd26b848f598@mail.gmail.com> On Wed, Nov 25, 2009 at 6:10 AM, Martin Pitt wrote: > Hello Victor, > > sorry for the late response; conference and all that.. > > Victor Lowther [2009-11-15 21:59 -0600]: > > And now, a version that actaully works. With a bit of glue code, this > > can replace auto quirk and smart kernel driver handling in pm-utils. > > I just tried your script, but AFAIK it just figures out the quirks > that are necessary on the _current_ system by parsing the .fdi > directly, right? > No, it translates the .fdi files that are currently on the system into a native format that uses bash-style extended regular expressions instead of the .fdi ad-hoc pattern matching scheme.. The translation is fairly simplistic right now (and could certainly do with being rewritten, in a language that acctually understands xml) but it only reads the .fdi files to translate them, and it only does that if they are newer than the native format files. If there are no .fdi files, or they are older than the native ones, it just uses the native format files. Take a look at maybe_update_native(), translate_xml() and their callers in the script for more details. > What I actually had in mind was that we should do a static conversion > to produce a simple-to-parse text file map which can then be put into, > and maintained within (well, it's not going to change often any more), > pm-utils itself, so that we can get rid of hal/hal-info completely. > > Would you want to change your script accordingly, or want me to work > on such a static conversion script? > No need, I already do that in the current script for convienence. Once we actually decide that this is the way forward, moving the XML translation into its own script or rewriting it in a language that actually understands XML will be pretty easy. > I thought about having one file per vendor, such as > > /usr/share/pm-utils/video-quirks/ibm > I already do this. > and each file would have a list of (dmi property:value)* ? quirks map like > > product_name:.*X31;bios-version:INET17WW s3_bios s3_mode > > which can then be matched against /sys/class/dmi/id/* with grep. > I tried that, it is hideously expensive -- you end up having to parse each line in the file in the shell, and then run grep on the specific DMI property you are looking at with the bits you parse out, which ends up running grep several hundred times. Since bash already knows about regular expressions, I cut out the middleman, and keeping the current treeish structure makes it easier to save a little time by not comparing the bits you do not actually care about. > Martin > > -- > Martin Pitt | http://www.piware.de > Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAksNHpgACgkQDecnbV4Fd/IQ/QCgvPBIp4E6Yt68mmStzEWsXZNt > jYwAn2f9GGomtquFSI5r5rHrIscFLNCZ > =JttI > -----END PGP SIGNATURE----- > > _______________________________________________ > hal mailing list > hal at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/hal > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freedesktop.org/archives/devkit-devel/attachments/20091125/222d465c/attachment.html