Active Topics

 


Reply
Thread Tools
glabifrons is offline glabifrons
2011-09-17 , 15:05
Posts: 149 | Thanked: 134 times | Joined on Jul 2007 @ Florida
#1
I've been trying to figure this out for a while now.
Yes, I've searched... for a while now. Googling "+(maemo OR n900) +dbus open close +(camera OR lense) +(cover or shutter)" doesn't return anything useful.

The problem is, according to "dbus-monitor --system", the same two signals are sent whether the camera cover is opening or closing.

Shutter opening:
Code:
signal sender=:1.13 -> dest=(null destination) serial=9631 path=/org/freedesktop/Hal/devices/platform_cam_shutter; interface=org.freedesktop.Hal.Device; member=PropertyModified
   int32 1
   array [
      struct {
         string "button.state.value"
         boolean false
         boolean false
      }
   ]
signal sender=:1.13 -> dest=(null destination) serial=9632 path=/org/freedesktop/Hal/devices/platform_cam_shutter; interface=org.freedesktop.Hal.Device; member=Condition
   string "ButtonPressed"
   string "cover"
Shutter closing:
Code:
signal sender=:1.13 -> dest=(null destination) serial=9636 path=/org/freedesktop/Hal/devices/platform_cam_shutter; interface=org.freedesktop.Hal.Device; member=PropertyModified
   int32 1
   array [
      struct {
         string "button.state.value"
         boolean false
         boolean false
      }
   ]
signal sender=:1.13 -> dest=(null destination) serial=9637 path=/org/freedesktop/Hal/devices/platform_cam_shutter; interface=org.freedesktop.Hal.Device; member=Condition
   string "ButtonPressed"
   string "cover"
This makes no sense to me at all.
One thing I noticed is dmesg does show the difference:
Code:
Nokia-N900:~# dmesg| grep shutter| tail -2 
[13739.665222] cam_shutter (GPIO 110) is now open
[13741.516632] cam_shutter (GPIO 110) is now closed
Unfortunately, that's not useful for triggering without being really kludgey.

Does anyone know what line I can use with dbus-scripts to distinguish camera cover opening from closing?
 

The Following User Says Thank You to glabifrons For This Useful Post:
jstokes is offline jstokes
2011-09-17 , 15:23
Posts: 235 | Thanked: 339 times | Joined on Nov 2010
#2
Maybe HAL is being slow. When opening the shutter, maybe you could wait a little bit longer and see if you get a similar line saying true for "button.state.value"

Alternatively, you might be able to just add a blanket watch for the "shutter opened" condition but then run "lshal -s -u /org/freedesktop/Hal/devices/platform_cam_shutter | grep button.state.value | awk '{print $3}'" in the script you plan have DBus-Scripts execute - if that command correctly returns the state of the shutter, you can just have if conditions that do whatever depending on if it returns "false" or "true"
 

The Following User Says Thank You to jstokes For This Useful Post:
glabifrons is offline glabifrons
2011-09-17 , 16:31
Posts: 149 | Thanked: 134 times | Joined on Jul 2007 @ Florida
#3
I left dbus-monitor running well after the camera app fired up, and all I saw was phone-status changes (signal strength, etc.).

I like your suggestion... that's a lot cleaner than "dmesg | grep shutter | tail -1 | awk '{print $NF}'".

Thanks!
 

The Following User Says Thank You to glabifrons For This Useful Post:
jstokes is offline jstokes
2011-09-17 , 16:38
Posts: 235 | Thanked: 339 times | Joined on Nov 2010
#4
Actually, sorry, but after looking at the lshal man page again, I saw a command called hal-get-property.

hal-get-property --udi /org/freedesktop/Hal/devices/platform_cam_shutter --key button.state.value is cleaner than the lshal solution above
 

The Following 2 Users Say Thank You to jstokes For This Useful Post:
glabifrons is offline glabifrons
2011-09-17 , 18:00
Posts: 149 | Thanked: 134 times | Joined on Jul 2007 @ Florida
#5
Ugh! I thought we had a winner here, but unfortunately, simply unlocking or locking the screen fires off the same dbus events (twice!) as opening or closing the camera cover!
Code:
=================================
Arg 1: :1.13
Arg 2: null
Arg 3: org.freedesktop.Hal.Device
Arg 4: PropertyModified
=================================
Arg 1: :1.13
Arg 2: null
Arg 3: org.freedesktop.Hal.Device
Arg 4: Condition
Arg 5: ButtonPressed
Arg 6: cover
=================================
I guess I should elaborate a bit on what I'm trying to do here.
I've set my N900 up to overclock (only 750) when I unlock the screen, then drop back to the default profile when I lock the screen (I plan to drop to a low voltage/slow profile after I get the rest finished).
This part works wonderfully with the following triggers:
Code:
/usr/local/bin/screenunlocked * * com.nokia.mce.signal tklock_mode_ind unlocked
/usr/local/bin/screenlocked * * com.nokia.mce.signal tklock_mode_ind locked
Unfortunately, my N900, though quite stable when overclocked with the voltage profile I'm using, will crash or lock up if I try and record video with those settings (obviously my DSP isn't as tolerant as my CPU). So, I want to have it drop down to the default profile when the camera door is open, but clock back up when the camera door closes again.

My current dbus-scripts setting for the camera trigger is:
Code:
/usr/local/bin/camerashutter * * org.freedesktop.Hal.Device Condition ButtonPressed cover
I decided to log each time each of the scripts were called and noticed this every time I unlocked the screen:
Code:
camerashutter called
screenunlocked called
camerashutter called
Similarly, every time I locked the screen:
Code:
camerashutter called
screenlocked called
camerashutter called
If I simply opened or closed the camera door, the expected happened:
Code:
camerashutter
I guess I still need a signal that can be reliably tied to the camera cover.
Any ideas?
 
Reply

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 10:45.

Contact Us - Home - Archive - Top