headers
David Zeuthen | 1 Sep 2005 01:03
Picon
Gravatar

Re: [patch] complete get and set lcd patch

On Wed, 2005-08-31 at 19:17 +0100, Richard Hughes wrote:
> Here's the latest complete patch as requested. Please review.
> 

Looks pretty good. Thinking about it we should call it LaptopPanel
instead of LCDPanel.. since that is exactly what it is. LCDPanel might
mean an external monitor connected via VGA or DVI.

Some other comments:

+static gboolean
+lcdpanel_refresh (HalDevice *d, ACPIDevHandler *handler)
+{

We need to test that the 'brightness' file.. or whatever it's called on
various systems actually exist.. And bail out (refuse to add the hal
device object) if it's missing. 

+	snprintf (path, sizeof (path), "%s/acpi/ibm", get_hal_proc_path ());
+	if (g_file_test (path, G_FILE_TEST_EXISTS))
+		acpi_synthesize_item (path, ACPI_TYPE_IBM_DISPLAY);

Maybe this should be "%s/acpi/ibm/brightness" instead? That would give
the check we need. Right?

+++ fdi/policy/10osvendor/16-lcdpanel-mgmt-policy.fdi	2005-08-31 18:31:15.000000000 +0100

Why 16? Why not just 10? :-)

+++ tools/hal-system-lcd-get-brightness	2005-08-31 19:00:35.000000000 +0100
(Continue reading)

Permalink | Reply | 5 comments |
headers
Danny Kukawka | 1 Sep 2005 01:18
Picon

Re: camera.* attribute proposal

On Wednesday 31 August 2005 22:36, Jeffrey Stedfast wrote:
[...]
> Now, here's what I propose:
>
> I propose that access_method becomes what it suggests it means, the
> actual access_method: 'ptp' 'storage' 'proprietary' etc...
> I also propose that camera.libgphoto2_support = true / false be present
> for those who all they care about is that.
>
> this means we have basically 4 possible scenarios (unless we want to get
> even more specific about proprietary access_methods)
>
> USB Mass Storage camera:
> info.category = 'camera'
> camera.access_method = 'storage'
> camera.libgphoto2_support = 'true'
>
> PTP camera:
> info.category = 'camera'
> camera.access_method = 'ptp'
> camera.libgphoto2_support = 'true'
>
> Proprietary access method camera with libgphoto2 support:
> info.category = 'camera'
> camera.access_method = 'proprietary'
> camera.libgphoto2_support = 'true'
>
> Proprietary access method camera without libgphoto2 support:
> info.category = 'camera'
> camera.access_method = 'proprietary'
(Continue reading)

Permalink | Reply | 502 comments |
headers
Artem Kachitchkine | 1 Sep 2005 01:39
Picon

Re: camera.* attribute proposal


> Currently there is a camera.access_method which, afaict, can currently 
> hold at least 2 values: 'ptp' and 'libgphoto2' where 'libgphoto2' 
> incldues at least usb mass storage cameras and some proprietary protocols.

According to the spec:

http://cvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html?only_with_tag=HEAD#device-properties-camera

camera.access_method can be either 'storage' or 'user'.
And there's the camera.libgphoto2.support boolean property that says 
whether the device is supported by libgphoto2.

0.5.4 also includes fdi/information/10freedesktop/10-camera-ptp.fdi, 
which sets access_method to 'ptp' for USB interfaces:

     <match key="info.bus" string="usb">
       <match key="usb.interface.class" int="0x06">
         <match key="usb.interface.subclass" int="0x01">
           <match key="usb.interface.protocol" int="0x01">
             <merge key="info.category" type="string">camera</merge>
             <append key="info.capabilities" type="strlist">camera</append>
             <merge key="camera.access_method" type="string">ptp</merge>

Kinda like what you've just proposed.

-Artem.
Permalink | Reply | 3 comments |
headers
Richard Hughes | 1 Sep 2005 02:15
Picon

Re: [patch] complete get and set lcd patch

On Wed, 2005-08-31 at 19:03 -0400, David Zeuthen wrote:
> On Wed, 2005-08-31 at 19:17 +0100, Richard Hughes wrote:
> > Here's the latest complete patch as requested. Please review.
> > 
> 
> Looks pretty good. Thinking about it we should call it LaptopPanel
> instead of LCDPanel.. since that is exactly what it is. LCDPanel might
> mean an external monitor connected via VGA or DVI.

Changed.

> Some other comments:
> 
> +static gboolean
> +lcdpanel_refresh (HalDevice *d, ACPIDevHandler *handler)
> +{
> 
> We need to test that the 'brightness' file.. or whatever it's called on
> various systems actually exist.. And bail out (refuse to add the hal
> device object) if it's missing. 
> 
> +	snprintf (path, sizeof (path), "%s/acpi/ibm", get_hal_proc_path ());
> +	if (g_file_test (path, G_FILE_TEST_EXISTS))
> +		acpi_synthesize_item (path, ACPI_TYPE_IBM_DISPLAY);
> 
> Maybe this should be "%s/acpi/ibm/brightness" instead? That would give
> the check we need. Right?

Yes, but then you need to scan the directory. I've done a proper fix
that you can check.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jeffrey Stedfast | 1 Sep 2005 02:51
Picon
Favicon

Re: camera.* attribute proposal

On Wed, 2005-08-31 at 16:39 -0700, Artem Kachitchkine wrote:
> > Currently there is a camera.access_method which, afaict, can currently 
> > hold at least 2 values: 'ptp' and 'libgphoto2' where 'libgphoto2' 
> > incldues at least usb mass storage cameras and some proprietary protocols.
> 
> According to the spec:
> 
> http://cvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html?only_with_tag=HEAD#device-properties-camera
> 
> camera.access_method can be either 'storage' or 'user'.
> And there's the camera.libgphoto2.support boolean property that says 
> whether the device is supported by libgphoto2.

yes, but unfortunately the only 2 values that get set in practice are
"ptp" and "libgphoto2" (at least on FC4 and SuSE "10")

> 
> 0.5.4 also includes fdi/information/10freedesktop/10-camera-ptp.fdi, 
> which sets access_method to 'ptp' for USB interfaces:
> 
>      <match key="info.bus" string="usb">
>        <match key="usb.interface.class" int="0x06">
>          <match key="usb.interface.subclass" int="0x01">
>            <match key="usb.interface.protocol" int="0x01">
>              <merge key="info.category" type="string">camera</merge>
>              <append key="info.capabilities" type="strlist">camera</append>
>              <merge key="camera.access_method" type="string">ptp</merge>
> 
> Kinda like what you've just proposed.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Artem Kachitchkine | 1 Sep 2005 03:17
Picon

Re: camera.* attribute proposal


> yes, but unfortunately the only 2 values that get set in practice are
> "ptp" and "libgphoto2" (at least on FC4 and SuSE "10")

Hmm, so either the spec is out of date or the gen-libgphoto-hal-fdi 
script incorrectly sets camera.access_method to "libgphoto2", when it 
should set it to "user" and camera.libphoto2.support to true.

-Artem.
Permalink | Reply | 1 comment |
headers
W. Michael Petullo | 1 Sep 2005 04:06

hal 0.5.4 and 15-storage-luks.fdi

It doesn't look like 15-storage-luks.fdi made it into the hal 0.5.4
tarball (or the recent Fedora RPM).  I do see hal-luks-remove and -setup
in there, and the LUKS stuff seems to work once 15-storage-luks.fdi is
installed from CVS.

--

-- 
Mike

:wq
Permalink | Reply | 1 comment |
headers
Danny Kukawka | 1 Sep 2005 09:50
Picon

Re: camera.* attribute proposal

On Thursday 01 September 2005 03:17, Artem Kachitchkine wrote:
> > yes, but unfortunately the only 2 values that get set in practice are
> > "ptp" and "libgphoto2" (at least on FC4 and SuSE "10")
>
> Hmm, so either the spec is out of date or the gen-libgphoto-hal-fdi
> script incorrectly sets camera.access_method to "libgphoto2", when it
> should set it to "user" and camera.libphoto2.support to true.

The gen-libgphoto-hal-fdi is out of date since libgphoto2 provides a own 
method to generate a fdi file (I don't know if this is already upstream). If 
there are any changes needed, let me know and I inform the developer at SUSE 
who wrote this for libgphoto2.

Cheers,

Danny
Permalink | Reply | 0 comments |
headers
Danny Kukawka | 1 Sep 2005 09:52
Picon

Re: hal 0.5.4 and 15-storage-luks.fdi

On Thursday 01 September 2005 04:06, W. Michael Petullo wrote:
> It doesn't look like 15-storage-luks.fdi made it into the hal 0.5.4
> tarball (or the recent Fedora RPM).  I do see hal-luks-remove and -setup
> in there, and the LUKS stuff seems to work once 15-storage-luks.fdi is
> installed from CVS.

The file is missing in the makefile. I fix this in cvs.

Cheers,

Danny
Permalink | Reply | 0 comments |
headers
John (J5) Palmieri | 1 Sep 2005 18:30
Picon
Favicon

Re: hal-0.4.8 and kde-3.4.2

On Wed, 2005-08-31 at 19:44 +0000, Dennis Veatch wrote:
> On Wednesday 31 August 2005 07:03 pm, John (J5) Palmieri wrote:
> > On Wed, 2005-08-31 at 18:39 +0000, Dennis Veatch wrote:
> > > The fstab gets updated with;
> > >
> > > /dev/hdc        /media/cdrecorder       auto
> > > pamconsole,exec,noauto,managed 0 0
> >
> > Does Lunar-Linux support pamconsole?
> 
> Well I have /lib/security/pam_console.so and /sbin/pam_console_apply and 
> Linux-PAM--0.79 installed. I assume, perhaps incorrectly those two files come 
> from there.

Then need to be part of your login chain.  Check to make
sure /var/run/console/ directory exists and a file with your username
and a console.lock file exist.  If they do not then you are not
configured to use pamconsole.  Mount simply checks the existence of your
username file to see if you are at the console and allowed to mount.
Pamconsole does some heuristics to determine if you logged in locally or
remotely and then places that file if you are local.  The first person
to login gets the console.lock.

--

-- 
John (J5) Palmieri <johnp <at> redhat.com>
Permalink | Reply | 0 comments |

Gmane