Richard Hughes [2009-07-02 17:47 +0100]:
> 2009/7/2 Martin Pitt :
> > On a related note, I had always wished g-p-m (and GNOME in general)
> > had a separate mode/policy for "laptop is docked", i. e. this exists:
>
> What would it do differently to the on AC case?
Nothing really. I contradicted my
2009/7/2 Martin Pitt :
> On a related note, I had always wished g-p-m (and GNOME in general)
> had a separate mode/policy for "laptop is docked", i. e. this exists:
What would it do differently to the on AC case?
Richard.
___
devkit-devel mailing list
d
On Thu, 02 Jul 2009 12:15:41 -0400
David Zeuthen wrote:
> On Thu, 2009-07-02 at 11:12 -0500, Robby Workman wrote:
> > > a) use standard configuration systems like e.g. GConf
> >
> >
> > GConf is not "standard" at all.
>
> Hence the term "e.g." - it means "for example".
>
> > If the goal is
Richard Hughes [2009-07-02 17:08 +0100]:
> So, I do need another property regardless to inform the prefs ui if
> the machine has a closable lid or not. We know this as we already
> monitor and export a property about the lid state.
I agree, forming default policies based on "how many batteries"/"l
Richard Hughes [2009-07-02 16:36 +0100]:
> Another thing, is we're exporting this as a property in
> DeviceKit-power, then the dmi data can be one source of information, a
> seed if you like. Other metrics could be if the system has more than 4
> disks it can be a server, but you get the idea. Not
On Thu, 2009-07-02 at 17:08 +0100, Richard Hughes wrote:
> So, I do need another property regardless to inform the prefs ui if
> the machine has a closable lid or not. We know this as we already
> monitor and export a property about the lid state.
>
> Ignoring form factor for a little bit, how abo
2009/7/2 David Zeuthen :
> No, it is not a goal for policy agents like gnome-power-manager to be
> desktop neutral - in fact, it's an anti-goal.
Right, it's called GNOME Power Manager because it depends on all the
GNOME stack.
Richard.
___
devkit-devel
On Thu, 2009-07-02 at 11:12 -0500, Robby Workman wrote:
> > a) use standard configuration systems like e.g. GConf
>
>
> GConf is not "standard" at all.
Hence the term "e.g." - it means "for example".
> If the goal is desktop-neutrality
> (which it should be, IMHO), then GConf should be out o
2009/7/2 David Zeuthen :
> Richard, I know you are just trying to push the envelope here and make
> things work out of the box - however, your assumption that a "form
> factor" value is available and trustworthy is just fundamentally flawed.
Okay, no worries, I'll agree that trying to be clever wi
On Thu, 02 Jul 2009 11:55:54 -0400
David Zeuthen wrote:
> On Thu, 2009-07-02 at 16:43 +0100, Richard Hughes wrote:
> > So, would a "is-laptop" property make more sense?
>
> No, no, no. You are conflating policy with the form-factor here. You
> are trying to be "helpful" but not realizing it's h
On Thu, 2009-07-02 at 16:43 +0100, Richard Hughes wrote:
> So, would a "is-laptop" property make more sense?
No, no, no. You are conflating policy with the form-factor here. You are
trying to be "helpful" but not realizing it's having the opposite
effect. That's what I've been trying to say all a
On Thu, Jul 2, 2009 at 11:43 AM, Richard
> stop talking about "Computer is low" and start talking about "Laptop
> is low" in the UIs.
Neither makes any sense to me...
___
devkit-devel mailing list
[email protected]
http://lists.freedeskt
2009/7/2 Bill Nottingham :
> laptop vs. is a form factor decision.
> Desktop vs. server is a use case decision.
True...
> While you can generally assume a 3U rack box or a blade is a server
> of some sort, it's much less clear for the 'desktop' form factors -
> they can just as easily be a 'serv
Richard Hughes ([email protected]) said:
> 2009/7/2 Kay Sievers :
> > Exactly, there is absolutely no way to tell what is a "server". Maybe
> > the "laptop" classification kind of works (can use better indications
> > for this), but there is no such thing as a "server" and "desktop" you
> > can
2009/7/2 Kay Sievers :
> Exactly, there is absolutely no way to tell what is a "server". Maybe
> the "laptop" classification kind of works (can use better indications
> for this), but there is no such thing as a "server" and "desktop" you
> can ever retrieve reliably from dmi data.
So DMI data is
On Thu, Jul 2, 2009 at 17:21, David Zeuthen wrote:
> On Thu, 2009-07-02 at 16:12 +0100, Richard Hughes wrote:
>> I really don't want to teach
>> gnome-power-manager about the niceties of dmidecode just so it can
>> choose the default policy in a sane way.
>
> No, just make g-p-m read settings from
On Thu, 2009-07-02 at 16:12 +0100, Richard Hughes wrote:
> > Yeah, maybe it dies for good with HAL, and we should not pretend to
> > know anything like this. Sounds like the best road to take from where
> > we are now.
>
> Then that's a regression.
Please don't use the word regression like that,
On Thu, 2009-07-02 at 17:08 +0200, Kay Sievers wrote:
> > Or maybe it turns out that we don't want something like this at all - I
> > mean, you can't really trust DMI data in the first place so it's rather
> > optimistic what Richard is trying to do. E.g. we don't want to give out
> > potentially w
On Thu, Jul 2, 2009 at 17:12, Richard Hughes wrote:
> 2009/7/2 Kay Sievers :
>> Yeah, it's a bit dangerous.
>
> Yes, I think virtual devices are a quick way back to the HAL mess.
> That's why I wanted to merge the data back to where it came from, so
> to speak. All it's doing is providing a mapping
2009/7/2 David Zeuthen :
> Or maybe it turns out that we don't want something like this at all - I
> mean, you can't really trust DMI data in the first place so it's rather
> optimistic what Richard is trying to do. E.g. we don't want to give out
> potentially wrong data.
Then we add quirks for th
2009/7/2 Kay Sievers :
> Yeah, it's a bit dangerous.
Yes, I think virtual devices are a quick way back to the HAL mess.
That's why I wanted to merge the data back to where it came from, so
to speak. All it's doing is providing a mapping for one key value to
another, with a DKP_ prefix.
> Yeah, ma
On Thu, Jul 2, 2009 at 17:09, Scott James Remnant wrote:
> On Thu, 2009-07-02 at 16:32 +0200, Kay Sievers wrote:
>
>> No, better don't stuff things into the dmi device, not all platforms have
>> that.
>>
> If they don't have a dmi device, then they won't have this information
> anyway.
>
> That's
On Thu, 2009-07-02 at 16:32 +0200, Kay Sievers wrote:
> No, better don't stuff things into the dmi device, not all platforms have
> that.
>
If they don't have a dmi device, then they won't have this information
anyway.
That's like saying we shouldn't put ID_FS_TYPE in block devices because
not
On Thu, Jul 2, 2009 at 17:01, David Zeuthen wrote:
> On Thu, 2009-07-02 at 16:46 +0200, Kay Sievers wrote:
>> On Thu, Jul 2, 2009 at 16:35, Richard Hughes wrote:
>> > 2009/7/2 Kay Sievers :
>> >> No, better don't stuff things into the dmi device, not all platforms have
>> >> that.
>> >
>> > Then w
On Thu, 2009-07-02 at 16:46 +0200, Kay Sievers wrote:
> On Thu, Jul 2, 2009 at 16:35, Richard Hughes wrote:
> > 2009/7/2 Kay Sievers :
> >> No, better don't stuff things into the dmi device, not all platforms have
> >> that.
> >
> > Then where in the database should this data go?
>
> There is no
On Thu, Jul 2, 2009 at 16:35, Richard Hughes wrote:
> 2009/7/2 Kay Sievers :
>> No, better don't stuff things into the dmi device, not all platforms have
>> that.
>
> Then where in the database should this data go?
There is no place in udev so far. We can't do that unless we invent
some fake devi
2009/7/2 Kay Sievers :
> No, better don't stuff things into the dmi device, not all platforms have
> that.
Then where in the database should this data go?
> This? http://cgit.freedesktop.org/~david/xdg-hostname/
That's the hostname, not the formfactor... Confused.
Richard.
___
On Thu, Jul 2, 2009 at 16:11, Richard Hughes wrote:
> One of the nice things about DMI data is that it gives you the form
> factor of the device, so you can choose sensible defaults for laptops,
> servers and handhelds. This data is exported in HAL, but not
> DeviceKit-*
>
> What about something li
One of the nice things about DMI data is that it gives you the form
factor of the device, so you can choose sensible defaults for laptops,
servers and handhelds. This data is exported in HAL, but not
DeviceKit-*
What about something like this:
SUBSYSTEM!="dmi", GOTO="dkp_formfactor_end"
ATTR{cha
Richard Hughes wrote:
> As we all know, the hal-ectimisation continues. At the moment,
> gnome-power-manager still uses HAL for two things:
>
> * Ambient light sensors
> * Setting the backlight on hardware without xrandr BRIGHTNESS support,
> or where xrandr falls over
>
> Now, I've held off adding
As we all know, the hal-ectimisation continues. At the moment,
gnome-power-manager still uses HAL for two things:
* Ambient light sensors
* Setting the backlight on hardware without xrandr BRIGHTNESS support,
or where xrandr falls over
Now, I've held off adding support for backlight devices to
De
2009/7/2 Martin Pitt :
> ACTION!="add", GOTO="ups_end" # drop this if you need change events, too
> SUBSYSTEM!="usb", GOTO="ups_end"
> KERNEL!="hiddev*", GOTO="ups_end"
>
> ATTRS{idVendor}=="0463", ATTRS{idProduct}=="", [... your action here ... ]
> [... similar idVendor/idProduct rules ...]
>
Hello Richard,
Richard Hughes [2009-07-02 9:14 +0100]:
> I'm trying to fix UPS support in DeviceKit-power. It's basically all
> down to incorrect udev rules. The device I'm trying to match is the
> last one in the chain, i.e. the one with DEVNAME=/dev/usb/hiddev0 :
> It's easy to match all device
On Thu, Jul 2, 2009 at 10:14, Richard Hughes wrote:
> I'm trying to fix UPS support in DeviceKit-power. It's basically all
> down to incorrect udev rules. The device I'm trying to match is the
> last one in the chain, i.e. the one with DEVNAME=/dev/usb/hiddev0 :
> It's easy to match all devices wi
On Thu, Jul 2, 2009 at 9:14 AM, Richard Hughes wrote:
> I'm trying to fix UPS support in DeviceKit-power. It's basically all
> down to incorrect udev rules. The device I'm trying to match is the
> last one in the chain, i.e. the one with DEVNAME=/dev/usb/hiddev0 :
>
> P: /devices/pci:00/:00
I'm trying to fix UPS support in DeviceKit-power. It's basically all
down to incorrect udev rules. The device I'm trying to match is the
last one in the chain, i.e. the one with DEVNAME=/dev/usb/hiddev0 :
P: /devices/pci:00/:00:1a.7/usb1/1-4/1-4.1
N: bus/usb/001/007
S: char/189:6
E: DEVPAT
36 matches
Mail list logo
