belcher_ has joined #maemo-leste
belcher has quit [Ping timeout: 268 seconds]
belcher_ is now known as belcher
kvw_5_ has quit [Ping timeout: 252 seconds]
kvw_5 has joined #maemo-leste
cockroach has quit [Quit: leaving]
antranigv has quit [Ping timeout: 240 seconds]
inky has quit [Ping timeout: 240 seconds]
sunshavi has quit [Read error: Connection reset by peer]
sunshavi has joined #maemo-leste
trench has joined #maemo-leste
antranigv has joined #maemo-leste
pagurus has quit [Ping timeout: 252 seconds]
<parazyd> sicelo: Install hildon-connectivity-location, upgrade existing packages, and reboot
<parazyd> Wizzup: ok. I'll have a look
<parazyd> Ir could also say something more useful.
pagurus has joined #maemo-leste
<parazyd> uvos: Gary said we coukd check netstat for connections to gpsd.
<parazyd> The problem is that anything else talking to gpsd will wake it up, and we want to avoid this.
<parazyd> Another issue is that the applet effectively becomes a client if we try to get any info from gpsd, i.e. fix status.
<kek> parazyd closed a pull request: https://github.com/maemo-leste/leste-config/pull/21 (resore ctrl-backspace on n900)
<freemangordon> parazyd: please look at my comment
<parazyd> freemangordon: Yeah I suppose at least devices with keyboard should have it.
<freemangordon> parazyd: why we shall keep separate configs for them? I think it is more simple like - enable it for all devices, no matter HW kbd or not.
<freemangordon> if currently h-d cannot support more than one shortcut per function, well, lets implement that
<freemangordon> but I think you should not merge that commit but instead have a discussion how to best handle that
* freemangordon is going afk for a while
<parazyd> ok, let's see what uvos says about that
<parazyd> Multiple shortcuts per function sounds good.
* parazyd afk too
uvos has joined #maemo-leste
<uvos> freemangordon: we had this discussion before, yes ctrl-backspace should work everywhere, no hildon cant assign more than one shortcut per action atm, yes this is a planed improvement
<uvos> also other shortcuts should work everywhere like alt-f4 same as mapphone "back"
cr4y1 has joined #maemo-leste
uvos has quit [Ping timeout: 260 seconds]
vectis_ has quit [Ping timeout: 240 seconds]
diejuse1 has joined #maemo-leste
<diejuse1> good morning
<diejuse1> I had to start from scratch, reinstalling the chroot Maemo image
<diejuse1> I had a problem. I can do ping to IP but "apt update" get the error "could not resolve host". I resolved this problem last time trying many thing but now I don't know what solution I used.
inky has joined #maemo-leste
<diejuse1> solved
diejuse1 has quit [Quit: Leaving.]
<freemangordon> uvos: do we have an issue about that(multiple shortcuts)?
inky has quit [Quit: Leaving.]
inky has joined #maemo-leste
Pali has joined #maemo-leste
<parazyd> freemangordon: No, I don't think we even considered it until now
<freemangordon> hmm, uvos said it has been discussed...
<freemangordon> ( 9,21,18) uvos: freemangordon: we had this discussion before, yes ctrl-backspace should work everywhere, no hildon cant assign more than one shortcut per action atm, yes this is a planed improvement
<freemangordon> I wonder who is 'we' here, as I don;t remember such discussion as well, but that could be my aging memory and lack of Fe
uvos has joined #maemo-leste
<freemangordon> parazyd: anyways, we shall have an issue for that, to not forget to fix/implement it
<freemangordon> I am going to open one
diejuse1 has joined #maemo-leste
<parazyd> I think he meant discussion for what should the shortcuts be
<parazyd> Thanks
<parazyd> (I'm still not at my computer)
<kek> freemangordon opened an issue: https://github.com/maemo-leste/bugtracker/issues/528 (hildon-desktop: implement multiple shortcuts per function)
diejuse1 has quit [Read error: Connection reset by peer]
diejuse1 has joined #maemo-leste
diejuse1 has quit [Quit: Leaving.]
diejuse1 has joined #maemo-leste
diejuse1 has quit [Read error: Connection reset by peer]
diejuse1 has joined #maemo-leste
<parazyd> Wizzup, uvos: So should I remove console=ttyS2 from mapphone boot.cfg?
<parazyd> Wizzup, uvos: Let's also think about how we can leste-config this file for existing users.
<Wizzup> would that mean we don't see the boot log?
<Wizzup> oh, by default, on serial
<parazyd> Wizzup: Yes on serial only. uvos said it should fix some (charging) bugs
<parazyd> We'd still keep it for the emergency shell
cr4y1 has quit [Ping timeout: 265 seconds]
cr4y1 has joined #maemo-leste
diejuse1 has quit [Read error: Connection reset by peer]
diejuse1 has joined #maemo-leste
diejuse1 has quit [Ping timeout: 260 seconds]
<pere> hm, just discovered my n900 is two minutes off correct time. is there no ntp involved to correct the time when there is internet around?
diejuse1 has joined #maemo-leste
<inky> i would setup openntpd
<inky> and do ntpd -s
<pere> by default, I mean.
<inky> but may be it has default ntp server, have no idea
<pere> (I know how to set up ntp, but that is beside the point. :)
<inky> no offence, i was doing that even on original maemo. love openntpd, don't like traditional ntp or systemde's service.
<inky> going even more offtopic, all openbsd software tends to be small and easy to use.
<inky> opensmtpd is one other example.
<Wizzup> pere: you could use gpsrecorder to get the time from gps
<Wizzup> I would advise against running certain nptd, as they cause immense wakeups and battery drain
<Wizzup> I think openntpd is one of them
<pere> Wizzup: so gps uses less power than ntpd?
<Wizzup> pere: if you one shot it, no
<Wizzup> I just advise against installed openntp djust to sync once
<Wizzup> since debian will auto start it and wreck your battery
<Wizzup> also if you connect, maemo should sync
<pere> one shot? in my book, a networked unit with a clock failing to automatically keep its clock correct is stupid. :)
<Wizzup> it oculd also be gotten from the cellular network
<Wizzup> in any case you're free to do whatever you want, I'm just telling you that it will wreck your battery life
<Wizzup> :P
<parazyd> pere: Try running ntpdate-debian -4
<pere> ok. intentionally stupid, I guess. :)
diejuse1 has quit [Quit: Leaving.]
<parazyd> Keep in mind the status time won't update immediately, so check with `date` in the shell
<uvos> parazyd: i would just add boot.cfg to leste-config
<uvos> normaly
<uvos> and add a preinst script to delet the current one
<uvos> and have it delete only if /boot/boot/boot.cfg is a link
<uvos> *is not a link
<uvos> so that it will just deleat it once and then overwrite only if the user has not changed it as normal
<uvos> some time in future then rm the preinst
<parazyd> ok, so semi-barbarian
<parazyd> Deal :)
<uvos> and then (on everything except rpi) we will have no orphan files, yay
<uvos> hmm
<uvos> can we also have it so that the boot.cfg is not deleted on leste-config uninstall
<uvos> just to guard a bit against the user being stupid
<Wizzup> I guess our boot.cfg is only for leste, right, so we would not likely mess up user config
<uvos> well
<uvos> the user might have a different partition layout
<uvos> than the image
<uvos> (i do)
<parazyd> uvos: I can only think of a hack where we would copy it in prerm
<parazyd> Maybe it's not a hack, but eh
<uvos> how dose the display work exactly
<uvos> will the device be renderd unbootable if a new leste-config is installed
<uvos> but apt dosent finish the posints setup stuff
<uvos> *displace not display
<parazyd> I can't give you a definite answer
<parazyd> The divert should be atomic for all I know
<uvos> ok
<uvos> maybe it would be safer if it where a seperate package
<uvos> that uses the same machinery as leste-config
<uvos> just so that it dosent get updated so often
<uvos> leste-kexecboot-bionic and leste-kexecboot-droid4 or whatever
<parazyd> Fine by me
<uvos> Wizzup: ?
<uvos> thoughts
inky has quit [Ping timeout: 240 seconds]
<parazyd> Nearly done with liblocation satellites
<Wizzup> separate package is probably easier yes
<Entitlement> parazyd - [ png (960 x 540) ]
<Entitlement> parazyd - [ png (960 x 540) ]
<Entitlement> parazyd - [ png (960 x 540) ]
<Wizzup> great
<Wizzup> what's with the missing icon/char?
<Wizzup> is that a degree character?
<parazyd> Yeah, might be missing in the font
<Entitlement> parazyd - [ gpsrecorder/WndSat.cpp at master · maemo-leste-extras/gpsrecorder · GitHub ]
<parazyd> It's some other unicode
<parazyd> Let me replace it with a proper one
<parazyd> Ugh I can't :D
<parazyd> Wizzup: Can you replace it with this one please : °
inky has joined #maemo-leste
<parazyd> oh or
<parazyd> Let me try something
<parazyd> ah nvm
<parazyd> Yeah, needs to be fixed
<parazyd> Wizzup: Would this work? http://sprunge.us/FwBQ7c
<Wizzup> I don't think so, hang on
<Wizzup> give me just a bit more time
<parazyd> No worries
<Wizzup> is there a way to test the charging mode yet, btw?
<Wizzup> parazyd: I am thinking of writing an article on debugging stuff
<Wizzup> there is no way to tell if something is -dbg or -dbgsym I think, right?
<parazyd> No, not really
<Wizzup> it should all be -dbgsym in the future, right?
<parazyd> Ideally all will be dbgsym when we port the remaining
<Wizzup> there is also stuff that is not from us that is -dbg
<Wizzup> e.g.
<Wizzup> python3.7-dbg - Debug Build of the Python Interpreter (version 3.7)
<Wizzup> did we do tests with python-location yet, I think I packaged it, right?
<Entitlement> Wizzup - [ Maemo Leste - Fourteenth Update (July, August, September, October, November, Dec... ]
<Wizzup> cool, it starts the applet
<tmlind> for boot.cfg, i'm using multiple partitions too
<uvos> "is there a way to test the charging mode yet, btw?" sure add softlevel=charge-mode to the kernel cmdline
<uvos> Wizzup:
<uvos> tmlind: we will have to break it once (the maemo boot.cfg) after that you should be able to restore your changes and have it be fine from there on out
diejuse1 has joined #maemo-leste
<tmlind> uvos: ok no problem with the file on my maemo partition, it only has maemo stuff
<Wizzup> uvos: fwiw I'm looking at the location-status crashes, will update later today
<Wizzup> freemangordon: what is a good way to debug hildon-status-menu applets again?
<Wizzup> gdb and maemo-invoker or something?
diejuse1 has quit [Ping timeout: 265 seconds]
inky has quit [Ping timeout: 246 seconds]
inky has joined #maemo-leste
jonsger has joined #maemo-leste
sicelo has quit [Quit: Bye!]
sicelo has joined #maemo-leste
halftux has joined #maemo-leste
random_yanek has quit [Ping timeout: 250 seconds]
random_yanek has joined #maemo-leste
<halftux> yeah finally I got the droid4 running with leste don't know if the files where corrupt or if the usb port is laggish. So booting the latest image and connecting it to usb makes the droid4 crazy with repeating messages from usb connection. Could you recommend an image which is most stable?
<halftux> hmm is there an droid4 image where usb network should work? I get a Multifunction Composite Gadget which vanishs when going pc suite mode..
<Wizzup> what kind of messages from usb?
<Wizzup> halftux: the default mode should be network
<Wizzup> don't select mass storage or pc suite
<uvos> you cant boot the device with usb plugged in atm or ever
<halftux> with messages I mean charging and disconnect charger and drain more power that it get ... now took other image and it looks like it is a bit less. I will try without mode and see.
<uvos> your usb cable has to high imedance
<uvos> *impedance
<uvos> charging fails and reconnects when the voltage sags to mutch
<halftux> okay so I used original Nokia N900 cable will see if I have another one.
<uvos> its finiky no doubt
<uvos> [20:44] <gemiller1> If 80mW is your budget, then gpsd is not for you.
<uvos> frendly
<Wizzup> they're not friendly it seems
<Wizzup> freemangordon: so I think I should use maemo-summoner to use gdb on programs
<Wizzup> yet gdb just shows the raise() from maemo-summoner
<uvos> im telling you guys this mameo launcher thing is more trouble than its woth it saves around 150ms application startup time over readahead-replay
<uvos> for being a pretty big pain in the but
<uvos> and thats absolute best case too
<uvos> most of the time it saves 0ms
<halftux> now using different laptop same cable and the droid4 is not crazy any more. So Sony sucks HP rocks. But still not able to get a usb network.
xmn has quit [Quit: ZZZzzz…]
<uvos> its just the d4 being picky atm
<uvos> we hope to solve this
<uvos> the sony is very likely in spec
<Wizzup> uvos: I think we benchmarked it to save quite a bit more, in any case, that's not the painful part per se tbh
xmn has joined #maemo-leste
<freemangordon> Wizzup: sorry, don;t get the issue. What is the backtrace?
<Wizzup> freemangordon: I am trying to debug a problem with parazyd's location-status applet
<Wizzup> It crashes every time when invoking something with osso, and I am pretty sure the code somehow doesn't set up the private struct, or it overrides the osso data somehow
<freemangordon> Wizzup: is that hildon-status-menu applet?
<Wizzup> so I'd really like to run valgrind on it, or gdb, but the only way I've been able to do it so far is to run it via dsme tool and attach with gdb
<Wizzup> yes
<freemangordon> so, just attach gdb to the second hildon-status-menu process
<freemangordon> or, start HSM with maemo-invoker
<Wizzup> so maemo invoker is the thing?
<freemangordon> sorry, maemo-summoner
<Wizzup> so if I do that, I still don't get the useful bits
<bencoh> maemo-summoner? is that a thing?
vectis_ has joined #maemo-leste
<Wizzup> like so:
<Wizzup> gdb --args maemo-summoner hildon-status-menu.launch
<bencoh> wasn't that invoker?
<freemangordon> well, I'd start it with:
<freemangordon> gdb maemo-summoner
<freemangordon> and then from gdb:
<freemangordon> r hildon-status-menu.launch
<freemangordon> bencoh: invoker starts it under launcher
<freemangordon> but we don;t want that
<freemangordon> Wizzup: also, maybe it needs to be started as user, by using run-standalone.sh to start gdb
<Wizzup> I did try various combinations of that, hang on, let me try
<Wizzup> of course now it doesn't segfault, sec
<Wizzup> most annoying thing about hildon-status-menu which annoyingly also makes sense: if it exits with non-sigint or non-normal, it disabled loading most plugins on next start
<Wizzup> ok, now I can gdb normally, weird
<Wizzup> I did try that earlier
<Wizzup> also I started this page: https://leste.maemo.org/Debugging
<Entitlement> Wizzup - [ Debugging - Maemo Leste Wiki ]
<Wizzup> parazyd: yeah so if I make osso_context_t the last var of the priv struct, it doesn't segfault, but still doesn't work
<Wizzup> something is messing with the priv stuff
<freemangordon> Wizzup: better run it under valgrind
diejuse1 has joined #maemo-leste
<parazyd> Could something in location-control be faulty?
<Wizzup> no
<Wizzup> I tried to launch the brightness one too
<freemangordon> hmm, where is the code?
<Wizzup> I have since modified the code, but can push it
<Wizzup> also with -Wextra there are some warnings libhildondesktop
<Entitlement> Wizzup - [ GitHub - maemo-leste/location-status at wip ]
<freemangordon> who initializes osso variable?
<Wizzup> p->osso = osso_initialize("location-sb", VERSION, TRUE, NULL);
<freemangordon> yeah
<Wizzup> location_status_menu_item_init does
<Wizzup> the segfault is in execute_cp_plugin, well rather, the osso_cp_plugin_execute code but it's not at fault - it's data gets corrupted
<freemangordon> BTW, why do we have 'priv' member of object struct?>
<Wizzup> I mirrored that after clock-plugin.c that you did
<Wizzup> in statusbar-alarm
<freemangordon> hmm, wait
<Entitlement> freemangordon - [ location-status/location-status.c at master · maemo-leste/location-status · GitH... ]
<freemangordon> what is obj?
<freemangordon> Wizzup: ^^^
<Wizzup> you're looking at master
<freemangordon> it should be "The GTK top-level widget" no?
<Wizzup> I pushed to wip, cleaned up the code some
<Wizzup> let me look
<Entitlement> freemangordon - [ LibOSSO: Plugins ]
<freemangordon> yes, please push
<Wizzup> I did
<Wizzup> 21:59 < Wizzup> freemangordon: https://github.com/maemo-leste/location-status/tree/wip
<Entitlement> Wizzup - [ GitHub - maemo-leste/location-status at wip ]
<Wizzup> the gpointer obj was very confusing to me too
<freemangordon> so, what is 'plugin'?
<Wizzup> ah, yeah, that seems like a problem
<freemangordon> is it gtk widget?
<freemangordon> mhm
<Wizzup> no, definitely not
<Wizzup> how did you see that so fast while I spend 4 hours on this
<Wizzup> lol
<freemangordon> you need to pass toplevel there, IIUC
<freemangordon> :)
<Wizzup> but making it 'NULL' didn't help, btw
<freemangordon> I am not sure you can pass NULL there, lemme check
<Wizzup> brightness applet does it
<freemangordon> could be
<Wizzup> if I make it NULL, I get this:
<Wizzup> ==3249== Invalid read of size 8
<Wizzup> ==3249== at 0x599B100: _dbus_transport_can_pass_unix_fd (dbus-transport.c:860)
<Wizzup> ==3249== by 0x59845EE: dbus_connection_send_with_reply_and_block (dbus-connection.c:3552)
<Wizzup> ==3249== by 0x59814A5: dbus_bus_name_has_owner (dbus-bus.c:1311)
<Wizzup> ==3249== by 0xA59AD8C: is_applet_running_in_cp (osso-cp-plugin.c:48)
<Wizzup> ==3249== by 0xA59AF7C: osso_cp_plugin_execute (osso-cp-plugin.c:135)
<Wizzup> which depends again on osso->conn this time
<Wizzup> ==3249== by 0xA5664BD: execute_cp_plugin (location-status.c:55)
<Wizzup> so just to be clear: the reason it segfaults before is because osso data is corrupted
<Wizzup> e.g. osso->cp_plugins is invalid ptr
<Wizzup> I checked the libosso code and that doesn't depend on the 'data' argument
<freemangordon> did you try to run it with 'run-standalone.sh'?
inky has quit [Ping timeout: 240 seconds]
<Wizzup> do you think that will be different somehow?
<freemangordon> looks like invalid dbus connection
<Wizzup> same problem
<Wizzup> so here's another thought
<Wizzup> if I take _LocationStatusMenuItemPrivate
<freemangordon> what about if you pass FALSE for user-cativated?
<Wizzup> and move osso data to the end of the struct
<Wizzup> it no longer segfaults
<Wizzup> but it doesn't work either
<Wizzup> which strongly suggests to me something is messing with the priv data
<freemangordon> mhm
<freemangordon> set data write breakpoint in gdb
<Wizzup> good point...
<Entitlement> freemangordon - [ location-status/location-status.h at wip · maemo-leste/location-status · GitHub ]
<Entitlement> freemangordon - [ location-status/location-status.c at wip · maemo-leste/location-status · GitHub ]
<Entitlement> freemangordon - [ location-status/location-status.c at master · maemo-leste/location-status · GitH... ]
<freemangordon> your private struct is not allocated correctly
<Wizzup> I rewrote the code in master because the priv struct was being corrupted
<Wizzup> so the same problem exists there
<Wizzup> also clock-plugin.c does this
<freemangordon> ok, if you say so
<Wizzup> omg
<Wizzup> my statusbar-alarm local code was out of date
<Wizzup> lol
<freemangordon> mhm:
<Entitlement> freemangordon - [ statusbar-alarm/clock-plugin.c at master · maemo-leste/statusbar-alarm · GitHub ]
<Wizzup> yes
<Wizzup> when I saw that I checked with git pull
<freemangordon> glad that I helped :)
<freemangordon> going to have some rest, night
<Wizzup> yt
<Wizzup> ty
<Wizzup> gn
<Wizzup> going to give up for today
<Wizzup> none of this makes sense
<Wizzup> parazyd: I don't think we can call dbus_connection_setup_with_g_main on the hildon status internal dbus
<Wizzup> removing the code doesn't necessarily help, but I don't think we should do that
<Wizzup> hm, looks like it is a new connection, so it should be ok..
<uvos> Wizzup: idk what you benchmarked
<Entitlement> uvos - [ Consider dropping maemo-launcher/maemo-invoker · Issue #479 · maemo-leste/bugtra... ]
<uvos> witch is absolutly best case
<uvos> as the 2nd app dose _nothing_ except symbol resolution
<uvos> and gtk setup
<Wizzup> did you do the test on the n900?
<uvos> yeah
<uvos> its more there
<uvos> around 150ms
<uvos> on d4 is about 60ms or so
<Wizzup> in any case I need to step away from the computer, I'm annoying by this location-status thing :)
<Wizzup> bbl
<uvos> bye
<uvos> fmg also claimed a ram usage advantage
<uvos> that i was unable to see at all
<uvos> with osso-xterm
<halftux> made with n900 and vm an apt update and upgrade (default repos) short after booting the screen is black. What went wrong is there a fix?
<uvos> on both?
inky has joined #maemo-leste
<halftux> yes using virtual machine in windows and on both no internet possible
<uvos> can you look at /tmp/xorg.log
<halftux> so in vm no input driver specified, ignoring this device.
<halftux> this device may have been added with another device file
<halftux> the last two lines
<uvos> do you have xf86-input-evdev installed (package might be named a bit differently)
<uvos> and do you have xf86-input-libinput
<uvos> but having no input devices really should not cause a black screen
<halftux> no I don't have it
<uvos> what now?
<halftux> i will install this package manually
<uvos> witch one
<uvos> xf86-input-libinput should be installed
<uvos> on vm
<halftux> but it is not installed
<uvos> and xf86-input-evdev on n900
<uvos> if xf86-input-evdev is installed on vm thats also fine
<uvos> you just need one of the 2 on vm and evdev on n900
<halftux> same
<halftux> ok I will try to install them
<uvos> should have been impossible on n900 for xserver-xorg-input-evdev to go missing
<uvos> as hildon-meta depends on it
<uvos> you dident uninstall hildon-meta right?
<Entitlement> uvos - [ hildon-meta/control at 09a05d18fa87965cd78a2aad892a1fa86b733a3a · maemo-leste/hi... ]
<Entitlement> uvos - [ hildon-meta/control at 09a05d18fa87965cd78a2aad892a1fa86b733a3a · maemo-leste/hi... ]
<uvos> i ment the second one
<halftux> ah ehmm I greped for xf86
<halftux> on n900 it is installed
<halftux> and on vm it is installed too ...
<uvos> can you upload the xorg log somewhere?
<uvos> from vm is fine\
<halftux> sure it will take some minutes
philipp_ has joined #maemo-leste
philipp_ is now known as uvos_
<uvos_> that looks fine
<uvos_> hmm
<uvos_> can you post pstree?
<uvos_> or check if hildon-desktop is running
<uvos_> or you can wait untill tomorrow
<uvos_> ill try the vm image
uvos has quit [Ping timeout: 260 seconds]
<uvos_> wierd
<uvos_> i dont see anything amiss
<halftux> this is pstree from n900 hildon-desktop seems to run
<halftux> I could see for short the hildon desktop
<halftux> I upgraded quite an old image
<uvos_> hmm
<uvos_> it still should work
<halftux> ok yes closing and openning again got it working again don't know what it was but it wasn't reacting on touch wired
<uvos_> dose the same thing work on vm
<uvos_> idk what to say
<sicelo> parazyd: thanks for Pavel video. Pity it's in Czech :-(
<halftux> hmm maybe I could change the input device on vm is ps/2 mouse maybe I should go touch
<sicelo> Or there's some 'magic' service that can help me make sense of what he says?
<uvos_> should work as is
<uvos_> its loading the right mouse driver
<uvos_> XINPUT: Adding extended input device "VirtualBox mouse integration" (type: MOUSE, id 9)
jonsger has quit [Ping timeout: 252 seconds]
<halftux> switch off with acpi shows lockscreen
<uvos_> thats correct
<halftux> but I can't manage to swipe
kek has quit [Read error: Connection reset by peer]
kek has joined #maemo-leste
<halftux> now I got configured usb-tablet and I still can't get rid of the black screen. But now I can swipe the lock screen.
<halftux> so this is only the screen saver which is bugging me
<halftux> so I disabled in the vm lock screen automatically and I can wake up the black display with mouse movements again
<uvos_> did you whilest uprading coose to keep any changes to /etc/mce.ini*
<uvos_> ?
<uvos_> if so your mce config setup is so old it dosent load the right modules
<halftux> no never did something like that
<uvos_> can you post your modules= line in /etc/mce.ini here
<halftux> hmm the file is from 18.01.2021
<halftux> it is from /etc/mce/mce.ini
<halftux> but in principle the problem is solved for me it was something with the lock screen and screen saver together that no input was recognized
<halftux> so now when I push the virtual acpi power switch the black screen goes away and when I press it again the power button menu shows up like before
<uvos_> yeah file looks fine
<halftux> thx for helping me analyse the problem
<uvos_> your welcome
Oksana has quit [Ping timeout: 252 seconds]
cockroach has joined #maemo-leste
halftux has quit [Quit: leaving]
Pali has quit [Ping timeout: 240 seconds]
uvos_ has quit [Ping timeout: 265 seconds]
cr4y1 has quit [Ping timeout: 265 seconds]