Re: [FSO 5.1] Preventing screen blanking
Am Mi 8. April 2009 schrieb Nicola Mfb: Suppose now that tangoGPS or navit, or other gps tools may do simply a couple of call to org.freesmartphone.Usage.RequestResource at startup, when the application exits the fso daemon automagically releases the resources: you obtain a on-click-and-do-not-suspend-dim-navigation-system-restoring-all-at-exit :)) please see and support http://trac.freesmartphone.org/ticket/393 /j signature.asc Description: This is a digitally signed message part. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO 5.1] Preventing screen blanking
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Angus Ainslie wrote:
On Tue, 2009-04-07 at 09:50 +0200, Ingvaldur Sigurjonsson wrote:
I wrote a little GUI using python-elementary which was a good way of
getting started using the dbus API. I use that to to turn on WiFi and
GPS, using the same methods as above, but with another resource ('WiFi'
and 'GPS'). This works at least on FSO milestone5.5 (built at home).
Regards
- Ingi
Hi Ingi,
Do you have the code for your GUI posted anywhere, is it GPL ?
Hi Angus
If you need code to to that, check out my little vala-settings (to be
renamed in the near future to shr-config or something like this). It's
an elementary GUI written in vala, so no python overhead, and it can be
used to turn on/off GSM/wifi/BT. GPS is on my list.
Personally, I use it to pop up a profile selection screen when pressing AUX.
The license is GPL2+ and the code is here:
http://github.com/spaetz/vala-settings/tree/master
(as I said, due to popular request, I will rename it soon, so that
location might change a bit). a .bb recipe for it is in the shr overlay.
spaetz
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkncXLUACgkQVYX1jMgnoGLqWgCfWGd5pqeVwdgqnjoEKmWo1m9n
zZkAoIrLnGCO0LmyN6fNax1GzVh9dqZm
=O1T4
-END PGP SIGNATURE-
___
support mailing list
support@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO 5.1] Preventing screen blanking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastian Spaeth wrote: I just went ahead and changed the name now, instead of http://github.com/spaetz/vala-settings/tree/master please use http://github.com/spaetz/shr-config/tree/master I'll update the SHR recipes accordingly. spaetz -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkncXbkACgkQVYX1jMgnoGLhQgCePQUe7SekZc0PGTv+2S54E7PV 3FoAnie1HnaOzYlc/9a5f9PUmNnZ0Ehj =VY7N -END PGP SIGNATURE- ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO 5.1] Preventing screen blanking
2009/4/8 Johny Tenfinger seba.d...@gmail.com Hem? Toggle for preventing screen from being blanked (and another for suspend) is for few mounths in shr-settings. And guess who implemented it :P (answer: that was me :p) That's fine, as the user has to be able to choose it's power management profile, however in a real scenario, you are in a car and want to start your navigation software, it's better you stop driving and park (this is in general good :)) as you have to launch srh-settings (it's slow, but it may depend on the fact I have a slow glamo clock for avoiding some problems with my sd card), and click some button, switch to illume, start your navigation application, when finished you switch back to shr-settings and reclick again. Suppose now that tangoGPS or navit, or other gps tools may do simply a couple of call to org.freesmartphone.Usage.RequestResource at startup, when the application exits the fso daemon automagically releases the resources: you obtain a on-click-and-do-not-suspend-dim-navigation-system-restoring-all-at-exit :)) I do not understand why this is so hard to implement! It may be that upstream developers does not want to add that snippet of code as their project is not distro-targeted, but distro mantainers may write a simple patch do add to the SRH/FSO recipes epository? It's only a consideration, when I'll begin to use GPS on my FR it may be I'll write those damned patches :) A question about shr-settings, do they interact with illume too to avoid illume blanking? Regards Nicola ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO 5.1] Preventing screen blanking
I've read the manual/wiki and I read the mailinglist but I cant recall
when I read about that stuff so here it comes again...
You can use 'mdbus' for this kind of stuff by using the dbus-methods
provided by the /org/freesmartphone/Usage (org.freesmartphone.ousaged):
Check the current ResourcePolicy:
$ mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \
org.freesmartphone.Usage.GetResourcePolicy 'Display'
(mine usually returns 'auto')
Set the ResourcePolicy to 'enabled' and the display wont undisplay it
self...
$ mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \
org.freesmartphone.Usage.SetResourcePolicy 'Display' 'enabled'
When I'm finished I usually set the ResourcePolicy back to 'auto' so the
battery wont drain.
I wrote a little GUI using python-elementary which was a good way of
getting started using the dbus API. I use that to to turn on WiFi and
GPS, using the same methods as above, but with another resource ('WiFi'
and 'GPS'). This works at least on FSO milestone5.5 (built at home).
Regards
- Ingi
Johny Tenfinger wrote:
RTM and don't ask questions, which are hundrets times on mailist. And
in meantime, request resource Display :P Or use SHR, which is FSO
based and has nice GUI for that in shr-settings... :P
2009/4/7, jeffrey.ratcli...@gmail.com jeffrey.ratcli...@gmail.com:
Whilst using the FR for navigation, it would be helpful if the screen
didn't blank.
In illume's power setup menu, there are two options, blank time, and
suspend time. However, blank seems to affect only the backlight, and
suspend turns off the screen. If I switch both to off, the backlight still
gets turned off after 30s and the screen itself 10s after.
How can I prevent either the backlight or the screen from turning off?
Regards
Jeff
___
support mailing list
support@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/support
Re: Re: [FSO 5.1] Preventing screen blanking
On Apr 7, 2009 9:50am, Ingvaldur Sigurjonsson i...@telia.com wrote: I've read the manual/wiki and I read the mailinglist but I cant recall when I read about that stuff so here it comes again... I looked before posting too... You can use 'mdbus' for this kind of stuff by using the dbus-methods provided by the /org/freesmartphone/Usage (org.freesmartphone.ousaged): I think that now FSO is not being funded, I'll switch to SHR, as previously suggested. Regards Jeff ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO 5.1] Preventing screen blanking
Johny Tenfinger, Perhaps the information is not clear in the manual, and perhaps the mailing list archive is not easily searchable, eh? Imagine walking into a pub, asking for the price for a beer and then being thrown out by the bouncer because you dared ask a question? So what if the price is on the wall? Maybe it was written in red letters on a green background, and I am colour blind. If you don´t have anything helpful to say, please do not post! The user uses FSO, not SHR, and RTM or RTFM is not a helpful statement. If the info is in the manual, point the user to the correct link! Please! By posting helpful links, Google and such will pick it up and these questions will go away! Mailing lists like these are for us, the users, and not meant to be a sterile environment. This is not an operating theatre in a hospital! Think Bazaar, not Cathedral! So what if the question was asked 100 times before? If 100 individuals asks the same question in their own words, you will have 100 different ways of looking at the problem, so you have 100 different pieces of meta information (context). If each of these 100 questions are answered, thousands of people out there have a lot better chance of getting accurate search results. Not all of us are technical gurus, merely adventurous individuals. If you post helpful answers, everybody (including you) wins. If you throw RTFM rants at people, all you do is make the list an unpleasant place to be. Be nice to people! Thanks. On Tue, April 7, 2009 06:35, Johny Tenfinger wrote: RTM and don't ask questions, which are hundrets times on mailist. And in meantime, request resource Display :P Or use SHR, which is FSO based and has nice GUI for that in shr-settings... :P 2009/4/7, jeffrey.ratcli...@gmail.com jeffrey.ratcli...@gmail.com: Whilst using the FR for navigation, it would be helpful if the screen didn't blank. -- Regards, Jan Henkins ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO 5.1] Preventing screen blanking
jeffrey.ratcli...@gmail.com wrote: I think that now FSO is not being funded, I'll switch to SHR, as previously suggested. I don't want to disappoint you, but SHR is FSO plus some UI and application goodness. So it still depends heavily on FSO going forward. spaetz ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO 5.1] Preventing screen blanking
Hello Johny, On Tue, April 7, 2009 10:35, Johny Tenfinger wrote: I understand, but really, really having n topics in mailbox about the same issue makes it difficult to follow more interesting questions and to provide more useful answers. About dimming screen: everyone even can find answer by using manually mdbus, as I, and then find some interesting dbus call for him. When you only ask, without trying to solve problem by yourself, you can't lern anything. I don't like people refering to manual at each question, but good heavens! How long you can answer the same question with the same content! I hope you understand my point. And I really want to be nice to people... If only they are nice too... I *do* understand your point. However, what you have to understand is that not everybody bought the FR for exactly the same reasons as you did, and even if they did are not nearly on the same technical level as you. They have but started their adventure! ;-) If somebody cannot see, switch on the light first and then they will be able to move by themselves in the direction you are pointing them. I am sorry if this upsets you, but that is life. 2009/4/7, Jan Henkins j...@henkins.za.net: Johny Tenfinger, Perhaps the information is not clear in the manual, and perhaps the mailing list archive is not easily searchable, eh? -- Regards, Jan Henkins ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO 5.1] Preventing screen blanking
I understand, but really, really having n topics in mailbox about the same issue makes it difficult to follow more interesting questions and to provide more useful answers. About dimming screen: everyone even can find answer by using manually mdbus, as I, and then find some interesting dbus call for him. When you only ask, without trying to solve problem by yourself, you can't lern anything. I don't like people refering to manual at each question, but good heavens! How long you can answer the same question with the same content! I hope you understand my point. And I really want to be nice to people... If only they are nice too... 2009/4/7, Jan Henkins j...@henkins.za.net: Johny Tenfinger, Perhaps the information is not clear in the manual, and perhaps the mailing list archive is not easily searchable, eh? Imagine walking into a pub, asking for the price for a beer and then being thrown out by the bouncer because you dared ask a question? So what if the price is on the wall? Maybe it was written in red letters on a green background, and I am colour blind. If you don´t have anything helpful to say, please do not post! The user uses FSO, not SHR, and RTM or RTFM is not a helpful statement. If the info is in the manual, point the user to the correct link! Please! By posting helpful links, Google and such will pick it up and these questions will go away! Mailing lists like these are for us, the users, and not meant to be a sterile environment. This is not an operating theatre in a hospital! Think Bazaar, not Cathedral! So what if the question was asked 100 times before? If 100 individuals asks the same question in their own words, you will have 100 different ways of looking at the problem, so you have 100 different pieces of meta information (context). If each of these 100 questions are answered, thousands of people out there have a lot better chance of getting accurate search results. Not all of us are technical gurus, merely adventurous individuals. If you post helpful answers, everybody (including you) wins. If you throw RTFM rants at people, all you do is make the list an unpleasant place to be. Be nice to people! Thanks. On Tue, April 7, 2009 06:35, Johny Tenfinger wrote: RTM and don't ask questions, which are hundrets times on mailist. And in meantime, request resource Display :P Or use SHR, which is FSO based and has nice GUI for that in shr-settings... :P 2009/4/7, jeffrey.ratcli...@gmail.com jeffrey.ratcli...@gmail.com: Whilst using the FR for navigation, it would be helpful if the screen didn't blank. -- Regards, Jan Henkins ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO 5.1] Preventing screen blanking
Oh, i forgot. If webarchive isn't useful, let's work on it! Saying only RTFM is wrong, but for me being nice regardless of situation is wrong too. Why now we are loosing our time on this topic? Because of unnecessary question we can't work on for example opimd integration at the moment. I know, that doesn't make any sense ;D But it's some kind of waste time. Our time and asker's time, because we are repeating, and he isn't learning anything. Finding informations is very usefull ability, not only in Openmoko world :) 2009/4/7, Jan Henkins j...@henkins.za.net: Johny Tenfinger, Perhaps the information is not clear in the manual, and perhaps the mailing list archive is not easily searchable, eh? Imagine walking into a pub, asking for the price for a beer and then being thrown out by the bouncer because you dared ask a question? So what if the price is on the wall? Maybe it was written in red letters on a green background, and I am colour blind. If you don´t have anything helpful to say, please do not post! The user uses FSO, not SHR, and RTM or RTFM is not a helpful statement. If the info is in the manual, point the user to the correct link! Please! By posting helpful links, Google and such will pick it up and these questions will go away! Mailing lists like these are for us, the users, and not meant to be a sterile environment. This is not an operating theatre in a hospital! Think Bazaar, not Cathedral! So what if the question was asked 100 times before? If 100 individuals asks the same question in their own words, you will have 100 different ways of looking at the problem, so you have 100 different pieces of meta information (context). If each of these 100 questions are answered, thousands of people out there have a lot better chance of getting accurate search results. Not all of us are technical gurus, merely adventurous individuals. If you post helpful answers, everybody (including you) wins. If you throw RTFM rants at people, all you do is make the list an unpleasant place to be. Be nice to people! Thanks. On Tue, April 7, 2009 06:35, Johny Tenfinger wrote: RTM and don't ask questions, which are hundrets times on mailist. And in meantime, request resource Display :P Or use SHR, which is FSO based and has nice GUI for that in shr-settings... :P 2009/4/7, jeffrey.ratcli...@gmail.com jeffrey.ratcli...@gmail.com: Whilst using the FR for navigation, it would be helpful if the screen didn't blank. -- Regards, Jan Henkins ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO 5.1] Preventing screen blanking
Maybe take a look on SHR Settings? Most of it should work in plain FSO, and I think there is no sense of duplicating work. ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO 5.1] Preventing screen blanking
Angus Ainslie wrote:
On Tue, 2009-04-07 at 09:50 +0200, Ingvaldur Sigurjonsson wrote:
I wrote a little GUI using python-elementary which was a good way of
getting started using the dbus API. I use that to to turn on WiFi and
GPS, using the same methods as above, but with another resource ('WiFi'
and 'GPS'). This works at least on FSO milestone5.5 (built at home).
Regards
- Ingi
Hi Ingi,
Do you have the code for your GUI posted anywhere, is it GPL ?
Thanks
Angus
Hi
The code is for 'my eyes only' for obvious reasons (you would be
frightened on how ugly code can be sometimes...).
I was just experimenting with the 'Toggle'-widget from Elementary so
I chop'ed and saw'ed from Elementary's 'test.py' to get a single Toggle
displayed.
The only addition is the '.changed'-callback addition which is really
simple in python i.e.
import elementary
...
import dbus
from dbus.mainloop.glib import DBusGMainLoop
DBusGMainLoop(set_as_default=True)
# Globals - Initialize dbus
bus = dbus.SystemBus()
# get a handle to org.freesmartphone.Usage-interface
o_usage = bus.get_object('org.freesmartphone.ousaged', \
'/org/freesmartphone/Usage')
if_usage = dbus.Interface( o_usage, 'org.freesmartphone.Usage' )
...
# Display enabled/auto
tg_disp = elementary.Toggle(win)
tg_disp.label_set(Display )
tg_disp.states_labels_set( enabled, auto )
if if_usage.GetResourceState('Display'):
# set to 'enabled' !
tg_disp.state_set( True )
else:
# 'auto' !
tg_disp.state_set( False )
# Connect callback
tg_disp.changed = tg_disp_changed
bx.pack_end(tg_disp)
tg_disp.show()
...
and then the callback:
def tg_disp_changed(obj, event, *args, **kargs):
if obj.state_get():
if_usage.SetResourcePolicy( 'Display', 'enabled' )
else:
if_usage.SetResourcePolicy( 'Display', 'auto' )
Right now I have Linux '2.6.29-GTA02_andy-tracking-mokodev' and on
that I have FSO milestone5.5. I've been using my Freerunner for a week
now and I'm almost satisfied with it (I bought it last september!).
Until the weekend I was missing all my contacts but I wrote a
vcard_import.py for Paroli's contacts (data is stored in the file
./paroli/contacts/phone by using python's pickle!) so now I'm no longer
dependent upon remembering all phone-numbers for my contacts (all three
of them...).
I'm currently building 'shr-unstable', and I'm going to give it a try
later tonight.
I enclosed the vcard_import.py if anyony is interested. It's of
course free for anyone to use etc...
Regards
- Ingi
#!/usr/bin/env python
# -*- coding: utf-8 -*-
import sys, getopt
import cPickle as pickle
g_verbose = False
class VCardContact:
def __init__( self ):
self.fn =
# dict with {type, number}
self.tel = {}
def reset( self ):
self.fn =
self.tel.clear()
def setName( self, name ):
self.fn = name.strip('\r\n')
def addPhoneNumber( self, type, number ):
self.tel[ type ] = number.strip('\r\n')
def to_list( self ):
return a list of entries for FN and numbers
phone_list = []
for e,v in self.tel.iteritems():
try:
u_nam_typ = unicode(self.fn + ' ' + e, encoding=utf-8, errors='replace' )
phone_list.append( [ u_nam_typ ,unicode(v)] )
except:
print Error appending entry for , self.fn, phone: , v
return phone_list
def importVCardFile( file, outfile ):
global g_verbose
# Read a VCARD-entry from file containing one or more entries
# Each entry may have following format.
# Starts with a 'BEGIN:VCARD', ends with 'END:VCARD'
# We're just extracting the fields 'FN' and 'TEL'
# - We'll add a name and a number for each TEL-subfield i.e. 'WORK', 'HOME', 'CELL'
# name + 'WORK' = number
# name + 'CELL' = number
#
# BEGIN:VCARD
# VERSION:2.1
# N;CHARSET=UTF-8:Sjöberg;Elisabet Eir
# FN;CHARSET=UTF-8:Elisabet Eir Sjöberg
# TEL;WORK;VOICE:0812341234
# TEL;CELL;VOICE:+46707774488
# EMAIL;PREF;INTERNET:elisa...@somewhere.se
# END:VCARD
contacts = []
cur_contact = VCardContact()
for line in file:
if line[0:11] == 'BEGIN:VCARD':
# Start with a new fresh entry
cur_contact.reset()
elif line[0:9] == 'END:VCARD':
# unpack a list of name+type = number into dictionary entry...
cur_list = cur_contact.to_list()
for i in cur_list:
# Phone dictionary entry only consists of 'tel' and 'name' fields
entry = {}
entry['tel'] = i[1]
entry['name'] = i[0]
if g_verbose:
print Adding entry , entry
contacts.append(
Re: [FSO 5.1] Preventing screen blanking
2009/4/7 Jan Henkins j...@henkins.za.net Johny Tenfinger, Perhaps the information is not clear in the manual, and perhaps the mailing list archive is not easily searchable, eh? Imagine walking into a [...] And perhaps in a better world, after reading hundreds of similar request for several months, navigation software developers my decide to add a checkbox to avoid screeen blanking and suspend, the same for small patches to apply by distro mantainers in the OE tree or in some launcher wrapper, but in the free world you are not cool if you are not able to play with yaml rules, enlightenment settings and mdbus :))) But if you want to feel better avoid mdbus and use dbus-send :) it's nice and fast, and you may enjoy in doing some kind of manual dbus introspection or reading the api usage directly :) http://wiki.openmoko.org/wiki/Jokes Nicola ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
Re: [FSO 5.1] Preventing screen blanking
Hem? Toggle for preventing screen from being blanked (and another for suspend) is for few mounths in shr-settings. And guess who implemented it :P (answer: that was me :p) 2009/4/8, Nicola Mfb nicola@gmail.com: 2009/4/7 Jan Henkins j...@henkins.za.net Johny Tenfinger, Perhaps the information is not clear in the manual, and perhaps the mailing list archive is not easily searchable, eh? Imagine walking into a [...] And perhaps in a better world, after reading hundreds of similar request for several months, navigation software developers my decide to add a checkbox to avoid screeen blanking and suspend, the same for small patches to apply by distro mantainers in the OE tree or in some launcher wrapper, but in the free world you are not cool if you are not able to play with yaml rules, enlightenment settings and mdbus :))) But if you want to feel better avoid mdbus and use dbus-send :) it's nice and fast, and you may enjoy in doing some kind of manual dbus introspection or reading the api usage directly :) http://wiki.openmoko.org/wiki/Jokes Nicola ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
[FSO 5.1] Preventing screen blanking
Whilst using the FR for navigation, it would be helpful if the screen didn't blank. In illume's power setup menu, there are two options, blank time, and suspend time. However, blank seems to affect only the backlight, and suspend turns off the screen. If I switch both to off, the backlight still gets turned off after 30s and the screen itself 10s after. How can I prevent either the backlight or the screen from turning off? Regards Jeff ___ support mailing list support@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/support
