**** BEGIN LOGGING AT Tue Nov 07 03:00:03 2017 Nov 07 05:31:22 WOW! Nov 07 05:31:26 ~+uptime Nov 07 05:31:27 - Uptime for purl - Nov 07 05:31:28 Now: 53d 8h 21m 10s running infobot 1.5.4 (SVN) -- linux Nov 07 05:31:28 1: 59d 8h 41m 19s running infobot 1.5.4 (SVN) -- linux, ended Sun Nov 14 18:39:57 2010 Nov 07 05:31:28 2: 57d 3h 9m 23s running infobot 1.5.4 (SVN) -- linux, ended Fri Jun 26 20:39:27 2009 Nov 07 05:31:28 3: 53d 8h 21m 11s running infobot 1.5.4 (SVN) -- linux, ended Tue Nov 7 05:31:27 2017 Nov 07 05:31:35 LOL Nov 07 05:37:13 FS Nov 07 05:37:17 CK Nov 07 05:37:39 ~+uptime Nov 07 05:37:40 - Uptime for purl - Nov 07 05:37:40 Now: 3m 8s running infobot 1.5.4 (SVN) -- linux Nov 07 06:18:49 * Maxdamantus wonders why pressing the headset button causes two apparent key presses. Nov 07 06:21:08 Pressing and releasing causes normal input events with `.code == 148` (and `.value == 0` or `.value == 1` depending on whether it's pressed or released) Nov 07 06:22:28 but after it's been released for around a second, it has another two events with `.code == 169, .value == 1` and `.code == 169, .value == 0` Nov 07 06:23:33 In Xorg, the first .code ends up as having symbol XF86Launch1, while the second one has symbol XF86Phone. Nov 07 07:44:40 ion and hilarity will Nov 07 07:44:40 ensue. Nov 07 07:44:53 ion? Nov 07 07:45:48 just a copypaste fail, mybad. morning! :) Nov 07 07:45:55 hi :) Nov 07 10:56:36 I imagine there will be some reason for that headset button functionality. You know what Maemo is like... Nov 07 10:57:06 maybe it sends button_down AND button_up ? Nov 07 10:57:25 would be logical for long press detection Nov 07 10:57:34 I read it as the second function only happens if pressed again within a second Nov 07 10:57:47 and that too Nov 07 10:59:34 Which I could imagine would be used by something. Why it's done in that way I wouldn't know. Nov 07 11:00:08 cost and usability Nov 07 11:09:26 It happens only if not pressed again within a second. Nov 07 11:10:02 So if you keep pressing the button, the second key press (XF86Phone) will not occur Nov 07 11:10:22 It will only occur a second or so after it hasn't been pressed/released. Nov 07 11:10:39 Can't remember if it happens while it's pressed .. /me checks Nov 07 11:11:30 Right, it doesn't. Nov 07 11:11:46 Only happens when the physical button has been in the released state for a second or so. Nov 07 11:16:30 Some way of controlling answering a phone call separately from the other functions the button does. Nov 07 11:18:52 Yeah, I guess so. Just seems weird that it would be implemented at that level. Nov 07 11:19:18 Dunno if it's the hardware itself, or the input driver in the kernel that generates the second key. Nov 07 11:19:56 Hmm .. I suspect the reason will be so that one program can bind to one key and another can bind to the other one. Nov 07 11:21:47 Since afaik, only one X11 connection can bind a particular key (XGrabKey) at a time. Nov 07 11:22:26 and you'd have to use something like XRecord to otherwise have multiple connections receiving the same key events. Nov 07 11:22:56 or be a parent window to the one that would normally be receiving them. Nov 07 11:27:33 phone application is is closed so it maybe difficult to find out. Nov 07 11:32:11 Well, it's probably not effectively going to have a difference unless something actually wants to grab the XFLaunch1 key. Nov 07 11:32:33 er, XF86Launch1* Nov 07 11:32:53 the phone UI seems to use XF86Phone, since it doesn't pick up if I keep pressing the button. Nov 07 11:48:40 Hmm .. wonder if the actual headset does something other than just short ground/mic while the button is pressed. Nov 07 11:49:09 I think it does, since the software behaves strangely when the headset is inserted while the button is pressed .. sort of. Nov 07 11:49:59 You would expect it to just be recognised as a normal pair of headphones, which seems to be what happens, but it doesn't show any headphone icon in the bar thing. Nov 07 11:50:17 It does still go to headphone mode, and doesn't produce the input device for the button. Nov 07 11:52:02 Might be nice to add a button next time I made a cable for my earphones. Nov 07 12:15:34 cat /sys/devices/platform/gpio-switch/headphone/state you can see there is an output depending on what is connected/detected. AV-out/headset/headphone etc Nov 07 12:19:14 actually there's a few places. probably thinking of /platform/nokia-av/detect Nov 07 15:32:45 ~+uptime Nov 07 15:32:46 - Uptime for purl - Nov 07 15:32:46 Now: 9h 52m 15s running infobot 1.5.4 (SVN) -- linux Nov 07 15:32:47 1: 59d 8h 41m 19s running infobot 1.5.4 (SVN) -- linux, ended Sun Nov 14 18:39:57 2010 Nov 07 15:32:47 2: 57d 3h 9m 23s running infobot 1.5.4 (SVN) -- linux, ended Fri Jun 26 20:39:27 2009 Nov 07 15:32:47 3: 53d 8h 24m 4s running infobot 1.5.4 (SVN) -- linux, ended Tue Nov 7 05:34:20 2017 Nov 07 15:51:45 ~+uptime Nov 07 15:51:46 - Uptime for purl - Nov 07 15:51:47 Now: 10h 11m 14s running infobot 1.5.4 (SVN) -- linux Nov 07 15:51:47 1: 59d 8h 41m 19s running infobot 1.5.4 (SVN) -- linux, ended Sun Nov 14 18:39:57 2010 Nov 07 15:51:47 2: 57d 3h 9m 23s running infobot 1.5.4 (SVN) -- linux, ended Fri Jun 26 20:39:27 2009 Nov 07 15:51:47 3: 53d 8h 24m 4s running infobot 1.5.4 (SVN) -- linux, ended Tue Nov 7 05:34:20 2017 Nov 07 15:56:28 Sigyn: <3 Nov 07 19:05:25 Yeah, so I guess it's "nokia-av" that's confused. Nov 07 19:06:49 the gpio driver correctly just reports "connected" and "disconnected", but nokia-av seems to print "3" in the "detect" node in sysfs when there's supposedly nothing plugged in. Nov 07 19:07:04 It continues showing "3" if I plug the headset in while holding the button. Nov 07 19:07:40 normally the headset appears as "4", and headphones appear as "1" Nov 07 21:53:52 Is there any potential for 'Firefox quantum' to be viable on N900? http://talk.maemo.org/showpost.php?p=1537953&postcount=81 Nov 07 21:55:38 problem as I see it is that "modern web" means megabytes upon megabytes of javascript for even simple "should be static html" pages. N900 is simply outdated for such, but fortunately still is the best phone in the world for qwerty shell action Nov 07 22:07:48 ergh so annoying why must the modern web not cater to lower powered devices, i.e. provide text-only option Nov 07 22:10:25 this is what gopherspace is for :D Nov 07 22:59:42 web designers don't care about performance only design. Gone are the days of divitis and flash, welcome to the age of the script Nov 07 23:00:32 well a broad stereotypical few there but ... :P Nov 07 23:03:31 * Maxdamantus still feels that browsers could generally do a better job at supporting lower-powered devices. Nov 07 23:04:26 Haven't looked particularly closely at Servo though (which I suspect is the basis of Firefox Quantum) **** ENDING LOGGING AT Wed Nov 08 03:00:02 2017