**** BEGIN LOGGING AT Wed Sep 13 03:00:01 2017 Sep 13 07:18:51 freemangordon: pong Sep 13 07:30:42 interestingly enough, on the blueborn android app, the N900 appears with a medium level of risk, while other Android devices come up with high risk Sep 13 07:30:59 *blueborne Sep 13 07:35:28 just simple stack protects should fix this issue\ Sep 13 07:35:36 e.g. any recent kernel with stack protector or any grsec kernel since like forever Sep 13 07:35:45 yet another argument for a modern sw stack : Sep 13 07:35:58 define 'recent' and 'forever' Sep 13 07:38:39 KotCzarny: hmm... 2004? earlier? Sep 13 07:38:45 (wrt forever) Sep 13 07:39:11 and you can look when CC_STACKPROTECTOR was introducted Sep 13 07:39:14 introduced* Sep 13 07:39:15 my 3.4 kernel has only 'oops on overwriting canary' style of stack protector Sep 13 07:39:57 no CONFIG_CC_STACKPROTECTOR_STRONG ? Sep 13 07:40:11 i think it was added around 3.14 Sep 13 07:40:19 https://lwn.net/Articles/584225/ Sep 13 07:40:21 well, it's been in grsec since like forever Sep 13 07:40:22 ;P Sep 13 07:41:13 wish you luck patching grsec into vendor kernels, he he Sep 13 07:41:22 there's a reason I don't use vendor kernels if I can Sep 13 07:41:31 if I can help it* Sep 13 07:41:40 yeah Sep 13 07:42:20 not that this is relevant any longer since they basically decide to go closed-source all the way Sep 13 07:42:45 well, gpl-compliant-but-distributed-to-customers-only-and-nobody-will-publish-it Sep 13 07:43:04 some people still have access, but yeah Sep 13 07:43:14 bottom line: "meh" Sep 13 07:43:27 yes. but I still stand with their vision on security :) Sep 13 07:43:32 same here Sep 13 07:43:41 also the 4.9 patchset is maintained for 2 years by minipli Sep 13 07:43:50 so it's not quite gone yet, and perhaps by the time they will have changed their mind Sep 13 07:43:59 oh, so he eventually picked up the project? Sep 13 07:44:05 only for 4.9 Sep 13 07:44:12 yeah, but ... that's cool Sep 13 07:44:13 he's maintaining the patchset again 4.9 lts Sep 13 07:45:10 is there still a chan for non-subcribers? I mean .... their former chan went private and we all got kicked, so ... Sep 13 07:46:29 there's #pax, but it's not super active Sep 13 07:58:29 wondering if setting https://www.armis.com/blueborne Sep 13 07:58:37 bleh Sep 13 07:59:14 /proc/sys/kernel/randomize_va_space can improve things a little for N900? Sep 13 07:59:29 currently it is 1, on Jolla it is 2 Sep 13 08:02:03 I wouldn't count on the n900 kernel being useful in this regard Sep 13 08:02:21 linus didn't take security seriously then, still mostly doesn't Sep 13 08:03:22 uhuh Sep 13 08:03:38 yes it doesn't solve the problem .. but there is mention, at least on Jolla pages, that ASLR can help a bit Sep 13 08:04:59 or just dont run bt all the time Sep 13 08:05:16 of course Sep 13 08:05:20 :)) Sep 13 08:05:29 which is much better battery-wise anyway :) Sep 13 08:09:50 weird that armis notified linux on 15th Auguest, when everyone else was notified around 4 months before Sep 13 09:40:14 Wanted to deal with companies that would agree to promote/advertise the companies findings first? Sep 13 11:12:18 where could one find the hildon-icons and/or sdk-default icons .deb ? Sep 13 11:36:15 According to the SDK repository information, the package osso-icons-default is marked "Provides: hildon-icons" Sep 13 11:37:21 ack Sep 13 11:37:42 then there's just that bug to fix. that package tries to overwrite a part of hicolor-icon-theme and doesn't manage to get instaled Sep 13 11:42:12 KotCzarny: name for "wind of change" would be Scorpions ehehe Sep 13 12:13:28 MaeScorpionsom :) Sep 13 12:16:54 how hard is to leave active hw keyboard when device is in sleep mode? Sep 13 12:17:48 would it be the same to just ssh to device? Sep 13 12:20:24 looking for some solution on to device Sep 13 12:21:53 it's simple leave touch enabled when device is in sleep mode, but dunno hw kb Sep 13 12:22:06 no idea. Maybe u wanna check "phone-control" wiki Sep 13 12:23:26 nothing there about that Sep 13 12:23:47 beats me, then Sep 13 12:31:24 huh? what's the problem? my kbd works great to undim screen Sep 13 12:31:46 and slide-open kbd unlocks device here Sep 13 12:33:17 ok, but how to enable hw kb and not to unlocks dev Sep 13 12:33:37 that's paradox Sep 13 12:34:39 locking device has the only purpose to not act on touchscreen and kbd events Sep 13 12:34:46 why? I can leave touch enabled when dev is in sleep mode, it's not paradox Sep 13 12:35:11 what is "in sleep mode", N900 never is in sleep mode Sep 13 12:35:26 he means locked and display off Sep 13 12:35:33 exacly Sep 13 12:35:38 locked as in switch locked Sep 13 12:35:44 not keycode locked Sep 13 12:36:09 yep, the whole purpose is "don't accept imput, don't show output" Sep 13 12:36:35 so "how do I accept input in 'don't accept input' mode?" is a paradox question Sep 13 12:37:00 he never mentioned this "don't accept input" mode ;) Sep 13 12:37:01 he means 'unlock only hwkb part' Sep 13 12:37:39 im interested of the use case of this hack. Sep 13 12:38:52 I suggest you redefine the function of lockswirch then, since it's not "lock" you want Sep 13 12:39:06 "lock" means "no input from kbd" Sep 13 12:40:39 http://paste.debian.net/plain/985874 the same but with hw kb Sep 13 12:40:44 maybe you only want to dim screen, or whatever. I faul to understand the purpose Sep 13 12:40:49 DocScrutinizer05: or it could mean "no input from screen" :) Sep 13 12:41:27 bencoh: definitely not since a lock also might involve device lock Sep 13 12:42:54 and the purpose of lock is to avoid any unintented input events, and dim screen so battery savings Sep 13 12:43:59 ok Doc, I'm looking for solution to turn off display & graphics chip, and it leaves hw kb enabled Sep 13 12:44:06 anyway the *purpose* is unclear Sep 13 12:44:22 that's easy :-) Sep 13 12:45:13 look to /etc/mce/mce.init, it defines dim times and levels Sep 13 12:45:40 then there's also the generic X11 screen lock Sep 13 12:47:10 if you only wanr brightness=0, there is a method in phonecontrol for that, or ask me if not Sep 13 12:47:53 but ondemand not with tklock Sep 13 12:47:53 jowever be aware that any kbd input will undim screen# Sep 13 12:49:09 looking sth independent for tklock Sep 13 12:49:38 mce.ini screen dimming is not tklock Sep 13 12:51:13 Tochscree+Keyboard-lock does what the name suggests Sep 13 12:52:23 when I slide open my device, screen goes dim, then black/off after 30s, any kbd press reactivates it Sep 13 12:52:41 so I think that's exactly what you want Sep 13 12:52:55 it's already there, see etc/mce/mce.ini Sep 13 12:54:02 no, I want use hw kb during screen is dim Sep 13 12:58:04 mce.ini can enable +/- but not whole hw kb Sep 13 12:58:36 forget tklock Sep 13 12:59:08 you do not want TtouchscreenKeyboarflock Sep 13 13:00:23 you don't get it, or I don't get it. I just told you my device accepts kbd input just fine even when after <30s>(adjustable) the display went completely dim Sep 13 13:00:57 for this the device does NOT tklock after 30s, just dims screen Sep 13 13:02:21 http://termbin.com/a06k Sep 13 13:05:30 ok, and after 30s when I use hw kb screen goes on, but I wish it stays dim Sep 13 13:05:43 that's the case Sep 13 13:06:15 see stuff like Sep 13 13:06:19 # Policy for keypad interrupts Sep 13 13:06:21 # Sep 13 13:06:22 # 2 - leave keypad interrupts on even after blanking Sep 13 13:06:24 # (used to support pass-through of +/-) Sep 13 13:06:25 # 1 - disable interrupts immediately Sep 13 13:06:27 # 0 to wait until display is blanked Sep 13 13:07:08 then you probably want to set brightness=0 Sep 13 13:08:02 unblanking screen on input events is embedded deeply inside X11 Sep 13 13:08:08 I'd guess Sep 13 13:08:37 not that blind typing would nake any sesne to me Sep 13 13:08:48 pretty much sounds like XY problem Sep 13 13:09:10 ~xy Sep 13 13:09:10 i heard xy is The XY problem: You want to do X, but don't know how. You think you can solve it using Y, but don't know how to do that, either. You ask about Y, which is a strange thing to want to do. Just ask about X. http://www.catb.org/~esr/faqs/smart-questions.html#goal Sep 13 13:09:25 blind typing, that's what I want Sep 13 13:09:51 magic sentence: blind typing Sep 13 13:10:21 ~wiki blind typing Sep 13 13:10:24 I couldn't find a matching article in wikipedia, look for yerselves: https://en.wikipedia.org/wiki/Special:Search?search=blind+typing&go=Go Sep 13 13:12:00 it would help a lot when you actually would explain what *exactly* you want to achieve, IOW what's the usage scenario Sep 13 13:12:22 but it will not blind, when run some app Sep 13 13:12:30 in a usage scenario, terms like tklock have to purpose Sep 13 13:13:36 yoz ask about technical means to achieve an obscure goal, please explain the real goal instead Sep 13 13:14:02 need it for example for mplayer Sep 13 13:14:27 err Sep 13 13:14:42 mplayer without display makes little sense, no? Sep 13 13:15:22 not for me at least Sep 13 13:15:30 xy Sep 13 13:15:45 ff_: there are media players that can run with screen off and reacting to some hw keys Sep 13 13:16:10 why the heck would I run a video media player without any display? Sep 13 13:16:16 and it for some short key, without using screen Sep 13 13:16:25 keys on the rim of the n900 are not normal kb, and can be left enabled Sep 13 13:16:41 and what's so nad about the display coming up anyway when I press a key to control the player? Sep 13 13:17:01 DocScrutinizer05: mplayer can be used as a music player as well I'd say Sep 13 13:17:05 media player doesn't have speed up tempo function Sep 13 13:17:13 depends on media player Sep 13 13:17:15 har har Sep 13 13:17:26 KotCzarny: please, dno't Sep 13 13:17:32 bencoh: and what's the terrible impact of display going active for 5 s when I press a key? Sep 13 13:18:02 bencoh: dont what? Sep 13 13:18:08 * KotCzarny is innocent of everything Sep 13 13:18:16 DocScrutinizer05: dunno, increased light in a dark room? :) Sep 13 13:18:31 the set brightness to zero!! Sep 13 13:18:39 then* Sep 13 13:18:45 or maybe he wants to avoid any touch input altogether Sep 13 13:19:06 or maybe he tells us what he wants Sep 13 13:19:23 she? Sep 13 13:19:54 bencoh is right Sep 13 13:20:22 but that's only one usage Sep 13 13:20:53 there's a solution to every requirement, but I'm not inclined to guess what might be the right selution whan you don't tell us the requirements Sep 13 13:21:27 this reminds me of the fact that we didn't solve the "tklock/codelock/powermenu interrupts mplayer audio playback for a second" Sep 13 13:21:36 specifying requirements by listing what doesn't work is not a feasible approach Sep 13 13:21:42 (or any player other than gst-mafw, basically) Sep 13 13:21:48 bencoh: if you ever find the cure, shout Sep 13 13:22:02 KotCzarny: I stopped looking for it tbh Sep 13 13:22:18 adding app to audio group works for a while, then it's reset by something Sep 13 13:22:29 that's what I thought then Sep 13 13:22:51 but iirc we eventually arrived to the conclusion that even that didn't always work(?) Sep 13 13:23:11 yeah, see the 'reset' part Sep 13 13:23:18 KotCzarny: has osc speed up tempo function? Sep 13 13:23:30 ff_: i have it in code, just didnt enable Sep 13 13:23:31 KotCzarny: no I mean, without "waiting for a while" Sep 13 13:23:46 but I kinda forgot Sep 13 13:23:50 ff_: i'm using code from sox for effects Sep 13 13:24:40 when i get around for next release code spree i will probably add it Sep 13 13:25:53 ~question Sep 13 13:25:54 i guess question is if you have a question and want people to give useful answers, make sure you have read this first: http://www.catb.org/~esr/faqs/smart-questions.html >>This guide will teach you how to ask questions in a way more likely to get you a satisfactory answer.<< Sep 13 13:26:51 KotCzarny: nice hint, I'll check it Sep 13 13:27:11 subscribe to the tmo thread, i post release notes there Sep 13 13:31:49 done Sep 13 13:39:45 N900 screen has 60Hz refresh rate, can it be 120Hz or sth around it? Graphic chip can handle max about 180Hz? Sep 13 14:13:12 Are you requiring multiple functions while the screen is off? Or just play/pause? Sep 13 14:13:32 for example Sep 13 14:14:40 would be nice to have 120Hz when device is on power adapter, and 60Hz on battery, but that probably needs some work with kernel / xorg / clutter or not? Sep 13 14:14:43 I can pause/play forward/backward with headset button but need some more Sep 13 14:15:17 You can make the device utilise the camera_focus while locked Sep 13 14:15:52 I use this for skip track Sep 13 14:19:06 need more than one or two, active hw kb is what I need Sep 13 14:21:21 I can use touch screen, but that wouldn't be precisely enough Sep 13 14:23:38 hmm, i wonder if there is a way to programatically enable hwkb without going through the normal unlock Sep 13 14:24:09 but i'm afraid screen lock takes over the display front Sep 13 14:24:18 and will receive the keys without passing further Sep 13 14:25:19 enable hwkb without going through the normal unloc Sep 13 14:25:38 k is what I'm looking for Sep 13 14:26:33 that way one could use rim keys to enable/disable hwkb, and maybe launch app to do some things Sep 13 14:26:59 if you arent afraid you might take a look into screenlock source Sep 13 14:27:09 what it does and maybe hack your way through it Sep 13 14:28:08 where that source is available? Sep 13 14:28:46 repo maybe? Sep 13 14:31:02 there are few lockscreen related packages in repos Sep 13 14:31:38 ok, I'll look for it Sep 13 14:31:38 depends on what you're referring to by "screenlock" Sep 13 14:31:59 you should check out mce Sep 13 14:32:03 (I guess) Sep 13 14:32:46 script for headset button & mplayer http://paste.debian.net/plain/985895 Sep 13 14:33:33 yes, mce unlocks +/- which is part of hw kb Sep 13 14:33:44 nothing 'tklock' related though Sep 13 14:34:05 ff_: ah, so you're basically trying to enable audio keys when locked? Sep 13 14:34:22 no, whole hw kb Sep 13 14:34:23 KotCzarny: that was actually the second thing we tried to understand re mplayer / audio groups Sep 13 14:34:31 Next bet is to use open source version of osso-systemui-tklock Sep 13 14:34:51 that's the "lock screen" Sep 13 14:34:56 (the one with the slider) Sep 13 14:35:15 iirc there isn't much there apart from the UI Sep 13 14:36:08 ((~questionenable hwkb without going through the normal unlock is what I'm looking for)) no, what you're looking for is an alternative to lock, and I still fail to understand the requirements of that alternative. *Maybe* they are: no touchscreen events, no energy waste on backlight Sep 13 14:36:20 https://github.com/community-ssu/osso-systemui-tklock Sep 13 14:36:37 dman mouse Sep 13 14:36:45 tklock plugin event eater window Sep 13 14:37:06 so yeah, there is a dummy window eating all events Sep 13 14:38:43 next thing would be checking if it still shows with screen off, or its done different way Sep 13 14:38:45 why mess with tklock when you simply could make your app display a black screen and discard all pointer events? Sep 13 14:39:06 because tklock probably shows on top Sep 13 14:39:09 it's totally pointless to mess around with stuff without knowing the requirements Sep 13 14:39:12 and eats all events Sep 13 14:39:32 KotCzarny: THEN DONT ENABLE TKLOCK! Sep 13 14:39:53 ... Sep 13 14:40:27 tklock is not the thing you look for Sep 13 14:40:44 DocScrutinizer05: as far as I'm concerned, I'd like a workaround to the fact that I can use volkeys with stock mediaplayer, but not with mplayer Sep 13 14:40:49 when you need to change/disable 90% of what it does Sep 13 14:41:02 that alone is good enough a reason for the workaround he's trying to achieve Sep 13 14:41:36 ff_ never really told what's the workaround to achieve Sep 13 14:41:58 always was xy Sep 13 14:42:07 "meh" Sep 13 14:42:23 from what I gather all the functions of mplayer without the screen Sep 13 14:42:43 hrm. where did i put gpio xh headers Sep 13 14:42:49 when you say you want tklock to learn to allow more than just F6/F7 aka Vol+/- keys enabled, then yes, that's a decent requirement spec Sep 13 14:43:29 and indeed a reasonable feature request Sep 13 14:45:02 however so far there's screen dim and there's tklock. For all requirements I heard so far screen dim is sufficient, doesn't need tklock. Sep 13 14:45:50 I am happy with play, skip forward and volume which is possible on locked device. I would imagine dim screen would be an issue if in a pocket... Sep 13 14:46:00 you might define a new function tklock/2 that doesn't lock the kbd Sep 13 14:48:15 when however the usecase is exactly "all the functions of mplayer without the screen" then I'd suggest to modify mplayer to show black screen and ignore touch input events Sep 13 14:48:55 then you don't need to mess up tklock function but simply never do tklock Sep 13 14:49:38 but that dosen't save power, 300mW wasted Sep 13 14:49:49 huh? Sep 13 14:50:19 graphic chispet is powered in that state Sep 13 14:50:34 then use X11 screenlock Sep 13 14:51:07 it's even a kernel function since 1986+- Sep 13 14:51:42 you can shut down display even in consoles Sep 13 14:52:01 no tklock needed Sep 13 14:52:25 is it on maemo? Sep 13 14:52:39 i think screen blank is supported by most systems Sep 13 14:52:50 since it's a genuine kernel function I'd hope yes it is Sep 13 14:55:55 keep in mind you need to enable display when your app loses focus (for ctrl-BS taskswitcher), or when a powerbutton-menu gets displayed, or when your app gets closed or receives a "enable display" hotkey Sep 13 14:57:13 but indeed what bencoh somwhat suggested (teach tklock to enable more buttons than just vol-keys) is a nice approach when implemented correctly Sep 13 14:58:08 since it avoids device deadlocks from a particular app blowing chunks and misbehaving Sep 13 14:58:55 can't be hard to augment the list of enabled-in-tklock keys arbitrarily Sep 13 15:00:21 see mce.ini Sep 13 15:00:23 # Policy for keypad interrupts Sep 13 15:00:24 # Sep 13 15:00:26 # 2 - leave keypad interrupts on even after blanking Sep 13 15:00:27 # (used to support pass-through of +/-) Sep 13 15:01:25 seems this is a never fixed regression in PR1.3 where that got hardcoded in mce instead of obeying to the mce.ini parameter Sep 13 15:02:24 so a subject for CSSU Sep 13 15:04:17 suggestion: re-implement that mce.ini parameter and augment to DisableKPImmediately=2,'list of keycodes to enable' Sep 13 15:05:27 if the list is empty, it defaults to +/- keys aka F6/7(?), otherwise only the listed keycodes are enabled. wildcard '*' allowed to enable all Sep 13 15:09:19 that would be a solution Sep 13 15:09:30 :-) \o/ Sep 13 15:10:50 :) Sep 13 15:13:08 hint to implementer: postinst script needs to edit mce.ini to set DisableKPImmediately=2 Sep 13 15:13:36 since that's what mce does right now, unconditionally Sep 13 15:17:39 ah, forgot evkey, duh, evkey -d -t -1 /dev/input/event1 , workaround but will be work Sep 13 15:21:10 can't find manpage and evkey has no decent -h Sep 13 15:21:25 so nfc what that does Sep 13 15:22:52 it wait until -d / down key press and prints its number Sep 13 15:23:17 -u wait until realese key Sep 13 15:25:44 -t wait until given time in ms Sep 13 15:26:10 -t -1 wait infinity Sep 13 15:32:41 sixwheeledbeast: ((I would imagine dim screen would be an issue if in a pocket...)) well, you hardly have kbd slide open when in pocket, and sliding open does unlock device anyway Sep 13 15:34:36 if it's only about the touchscreen events that need to get blocked, there are other possible approaches than tklock Sep 13 15:35:32 it's always also a question if that behavior is appropriate regardless of the app that has focus Sep 13 15:37:33 ((that behavior)) to e.g. disable ts-events. Probably it would be better to let app just consume the events but process them in a different way - immediately blank screen again - when screen blanked Sep 13 15:41:47 while true; do evkey -d -t -1 /dev/input/ts; dbus-send foo.mce mce/dimscreen; done Sep 13 15:42:21 -s print numbers of all pressed keys Sep 13 15:45:57 of course THIS (my evkey thing) is not the right solution since it's completely bypassing X11 event pipeline and thus is unaware of app losing focus Sep 13 15:46:49 it's just sketching what the mainloop in app should do when receibing a touchscreen X11 input event Sep 13 15:46:56 dbus-send mcs/dimscreen is interesting this one: dbus-send --system --type=method_call --dest="com.nokia.mce" --print-reply "/com/nokia/mce/request" com.nokia.mce.request.get_tklock_mode or different? Sep 13 15:47:43 I'd think it's rather set_thlock or somesuch Sep 13 15:48:05 ~phonecontrol Sep 13 15:48:06 hmm... phonecontrol is http://wiki.maemo.org/Phone_control Sep 13 15:48:36 http://wiki.maemo.org/Phone_control#Lock_screen_and_keys_.28slider_lockswitch.29 Sep 13 15:48:39 right dbus-send --system --type=method_call --dest=com.nokia.mce /com/nokia/mce/request com.nokia.mce.request.req_tklock_mode_change string:"locked" that one? Sep 13 15:48:44 ooh nope Sep 13 15:50:46 is it simple to higher display freshrate in maemo? default is 60Hz Sep 13 15:51:30 ok, thank you with hw kb, now it is quite simple Sep 13 15:51:31 no Sep 13 15:54:18 http://lists.maemo.org/pipermail/maemo-developers/2010-May/026195.html doing "the opposite" Sep 13 16:10:24 http://lists.maemo.org/pipermail/maemo-developers/2010-May/026202.html >>Thanks, the first method (dbus) works with no issue<< MEH not for me Sep 13 16:18:10 dman lack of dbus introspection on all Nokia dbus services. alegedly since "impossible in this coding environment" ROTFL Sep 13 16:22:16 yes, some dbus inspector would be helpful Sep 13 16:24:39 maybe d-feet ? Sep 13 16:26:06 the services themselves don't support introspection Sep 13 16:26:15 they lack the data/functions for it Sep 13 16:26:26 from strings mce: Sep 13 16:26:28 /sys/class/i2c-adapter/i2c-1/1-004a/twl4030_keypad/disable_kp Sep 13 16:26:29 /sys/devices/platform/i2c_omap.2/i2c-0/0-0045/disable_kp Sep 13 16:26:31 /sys/devices/platform/omap2_mcspi.1/spi1.0/disable_kp Sep 13 16:26:32 /sys/devices/platform/omap2_mcspi.1/spi1.0/disable_ts Sep 13 16:26:34 /sys/devices/platform/omap2_mcspi.1/spi_master/spi1/spi1.0/disable Sep 13 16:27:00 dafaq!! Sep 13 16:27:02 [Notice] -Sigyn- Your actions in #maemo tripped automated anti-spam measures, but were ignored based on your time in channel; stop now, or automated action will still be taken. If you have any questions, please don't hesitate to contact a member of staff Sep 13 16:27:15 ;-P Sep 13 16:38:13 repeating pattern. My fault Sep 13 16:38:36 should have used pastebin Sep 13 16:44:01 found string "DimImmediately" Sep 13 16:48:53 ~sources Sep 13 16:48:54 I guess you mean the handhelds sources, see http://handhelds.org/sources.html Sep 13 16:48:59 ~source Sep 13 16:49:00 To build Debian packages from source code: first, add a deb-src line to your sources.list file. Then "apt-get build-dep _pkg_" and "apt-get -b source _pkg_" to retrieve the build-dependencies, and the source. The resulting .deb files will be in `pwd`. Sep 13 16:49:03 dang Sep 13 16:52:11 there it is https://gitorious.org/community-ssu/mce but why T F is https://gitorious.org/community-ssu/ a 404? Sep 13 17:04:08 https://gitorious.org/community-ssu/mce?p=community-ssu:mce.git;a=blob_plain;f=tklock.c;hb=HEAD "static gboolean ts_event_control(gboolean enable)" and "static gboolean kp_event_control(gboolean enable)" Sep 13 17:04:26 no idea where the system filters for F6/7 Sep 13 17:06:14 I guess static gboolean generic_event_control() just uses the above mentioned sysfs nodes and writes 1 or 0 to */enable Sep 13 17:07:21 as in return generic_event_control(mce_keypad_sysfs_disable_path, enable); Sep 13 17:14:33 static gboolean disable_eveater(gboolean silent); sounds interesting but defned elsewhere, so... I'm lost Sep 13 17:15:53 forget about it, evkey is good enough for that purpouse Sep 13 17:16:53 typedef enum { [...] /** Event eater UI active */ MCE_TKLOCK_UI_EVENT_EATER = 2, [...]} tklock_ui_state_t; Sep 13 17:21:26 yes, eater, as KotCzarny mencioned, is responsible for catching all key press Sep 13 17:22:50 *mentioned Sep 13 17:34:12 yes, and AIUI it's not getting enabled when vol-keys are active ib tklock Sep 13 17:34:47 so *all* key events should get through, and I don't know if anything else will filter out all but F6/7 Sep 13 17:35:44 hmm, prolly can test this Sep 13 17:40:09 OK, DisableKPImmediately=2 indeed keeps keyboard events enabled, at least on evkey -d -t -1 /dev/input/event1 level Sep 13 17:41:44 I *guess* apps like mediaplayer which want receive Vol+/- events while tklock are bypassing mce completely and enable keyboard via sysnode directly Sep 13 17:43:28 indeed *everything* seems to receive all kbd events even in tklock when DisableKPImmediately=2, so I guess here you are :-D Sep 13 17:44:30 tested desktop ctrl-BS (taskswitcher), and "test" ascia, bit resulted in expected action triggered while tklock and display dark Sep 13 17:45:09 s/ascia, bit/ascii, both/ Sep 13 17:45:09 DocScrutinizer05 meant: tested desktop ctrl-BS (taskswitcher), and "test" ascii, both resulted in expected action triggered while tklock and display dark Sep 13 17:45:43 bencoh: ^^^ Sep 13 17:48:15 bencoh: sed -i 's/DisableKPImmediately=./DisableKPImmediately=2/' /etc/mce/mce.ini; stop mce; start mce Sep 13 17:49:19 slide open kbs, start mplayer, tklock, check vol-keys Sep 13 17:49:35 check other keys as well Sep 13 17:51:28 ROTFL! or - instead `stop MCE; start mce` maybe just try `mce --version` Sep 13 17:51:55 http://paste.ubuntu.com/25529012 Sep 13 17:53:52 blindtyping in xchat Sep 13 17:54:20 ff_: see this??? Sep 13 17:56:48 file closed Sep 13 17:59:40 so let me rephrase: I *guess*^H^H^H KNOW apps like mediaplayer which want receive Vol+/- events while tklock are bypassing mce completely and enable keyboard via sysnode directly and EVIDENTLY *everything* receives all kbd events even in tklock when DisableKPImmediately=2 Sep 13 18:00:32 ff_: any other questions? Sep 13 18:05:20 here vol +/- works, but not others keys, even playing mplayer or media player, maemo stock here Sep 13 18:06:01 check your mce version Sep 13 18:06:13 check DisableKPImmediately=2 Sep 13 18:06:43 I typed to xchat while in tklock, so why would mplayer not receive *all* keypresses as well Sep 13 18:07:06 older Sep 13 18:07:08 mce v1.8.126 Sep 13 18:07:19 get CSSU mce then Sep 13 18:10:08 actually i'm ahppy about that, I've not been mistaken on the regression in PR.13 mce, just I didn't know it was fixxed in CSSU already Sep 13 18:10:48 DisableKPImmediately=2, ok, newer version is needed, thx for that solution Sep 13 18:10:59 yw :-D Sep 13 18:14:18 is there a maemo music player with GUI that allows to shuffle-play a directory of music files? Sep 13 18:14:29 yes! Sep 13 18:14:36 can you reccomend one? Sep 13 18:14:42 ~oscp Sep 13 18:14:42 i heard oscp is http://talk.maemo.org/showthread.php?t=94590 Sep 13 18:14:48 that was fast, even for you ;-P Sep 13 18:15:26 nah, it was slow. i had to type /msg #maemo etc Sep 13 18:16:05 konversation has nice cmd aliases Sep 13 18:16:09 ;-) Sep 13 18:16:14 /9 is Sep 13 18:16:18 http://talk.maemo.org/showthread.php?t=91142 Sep 13 18:16:42 i'm too lazy to write my /alias'es Sep 13 18:17:41 when did that get a gui? Sep 13 18:17:58 1.6 years ago Sep 13 18:18:50 very nice, thanks Sep 13 18:19:29 could it work on sailfishOS? Sep 13 18:19:38 nope Sep 13 18:19:56 i have n9, but havent gotten around to port it yet Sep 13 18:21:28 it says disconnected Sep 13 18:21:34 yes Sep 13 18:21:37 it's the gui Sep 13 18:21:41 did you read first time help? Sep 13 18:21:59 in short, it consist of server (core) and remote (ui) Sep 13 18:22:15 press 'gears' icon to spawn core Sep 13 18:22:16 where to i press to see first time help? Sep 13 18:22:20 ok ty Sep 13 18:23:19 ui can connect to local or remote core (ie. you can control media player running on windows or linux from your n900 Sep 13 18:24:59 and it's true the other way round too, ie. you can use your laptop/pc to control media playing on n900 Sep 13 18:25:05 ok i navigated to my podcasts directory Sep 13 18:25:25 how do i shuffle play all files in this directory? Sep 13 18:25:42 enable [S]huffle mode and just press 'next' Sep 13 18:25:45 or 'play' Sep 13 18:26:00 i press "s"? Sep 13 18:26:04 yes Sep 13 18:26:13 either on kb or the button on screen Sep 13 18:26:15 then "p"? Sep 13 18:26:31 dont remember the kb shortcut, might be 'n' for next Sep 13 18:26:44 or space for 'play/pause' Sep 13 18:26:50 p moves me to next line in the directory listing Sep 13 18:27:11 space works and moves me to next song Sep 13 18:27:31 's' didn't enable shuffle, but S icon did Sep 13 18:28:08 as i've said, dont remember n900's shortcuts. i use it mostly on my laptop, and sometimes on n900 on the go (but then using ui) Sep 13 18:28:37 are the [1] [2] icons in the left for playlists? directory shortcuts? Sep 13 18:28:55 they are for storing favs Sep 13 18:29:06 might be dir/file/http link shortcuts Sep 13 18:29:16