| kona_ | pinephone hwkbd is out | 00:58 |
|---|---|---|
| xmn | yuppers, review are slowly popping up. And thing like dont charge it through the phones usbc port if you have it hooked up to the phone. | 01:00 |
| kona | def dont | 01:17 |
| kona | that will likely fry something | 01:17 |
| kona | kbd takes some fiddling to get working on mobian but it does work. | 01:18 |
| kona | activation distance is a bit unforgiving, which leaves the keyboard feeling mushy and unresponsive, but eliminates some unintentional keypresses | 01:20 |
| kona | phone fits in it very well, and it feels solid once assembled | 01:21 |
| kona | hinge is stiff, which is good for mobile use but might give trouble for people with grip issues | 01:23 |
| uvos | is there a hw way to dect if its closed? | 01:26 |
| huckg | uvos: Thanks for the help yesterday with bionic audio, I boosted the volume by editing HiFi.conf. 5 was really very quiet. | 01:33 |
| kona | uvos: not sure, just got it | 01:44 |
| kona | no, pp hwkbd schematic shows no hinge sensor | 02:40 |
| xmn | kona, uvos maybe there could be a gyro software solution that turn on when your using the if2 connection to sleep when closed and start up when open a certain way. | 07:56 |
| xmn | btw, kona I forget it does have backlighting right? Are you happy so far with it? | 07:57 |
| humpelstilzchen[ | I would have thought of the proximity sensor for keyboard detection, but maybe use proximity and IMU | 08:04 |
| kona | xmn: there's a couple of interesting possibilities. the keyboard has a single button that is separate from the phone's power button. according to the drivers, its status can be polled, including long press, short press, double-press, and no press (open) | 08:06 |
| kona | prox sensor might be a way to do it. | 08:06 |
| kona | i was also thinking that since there's an i2c input daemon, it could signal the UI to remove the OSK when keystrokes are detected, and to re-enable OSK when the keyboard is idle a certain amount of time. | 08:08 |
| xmn | ah, yeah forgot about the prox! maybe combine with the accelerometer | 08:08 |
| xmn | would be nice to turn off keyboard keystroke when using certain apps like the phone apps | 08:10 |
| kona | accel is another great way to do it, although it would have to have tolerance for cases where the screen might be slightly tilted | 08:10 |
| kona | firmware is totally open, and gets loaded as far as i can see by the drivers. | 08:10 |
| xmn | yeah you would need a profile for speed likely or something. I'm no dev :P | 08:10 |
| kona | so there's a bunch of customizations we could do. | 08:10 |
| xmn | yeah hopefully in a years time we have lots of options | 08:11 |
| kona | in theory i2c input daemon knows whether it is successfully polling the kb, maybe could find a way to use the presence or absence of a poll response. | 08:13 |
| xmn | hmm, interesting idea | 08:13 |
| kona | and could also mod the daemon to activate and deactivate OSK | 08:13 |
| xmn | so you could basic block the polling when using the phone apps etc | 08:14 |
| kona | based on button presses | 08:14 |
| xmn | see I not sure button press would be enough if you had to take a call in the case and don't have time for headsets | 08:14 |
| xmn | I'm* | 08:15 |
| kona | i suppose that's a possibility, but i don't have a lot of knowledge about how the maemo OSK works, as evidenced by my prior questions in here. | 08:15 |
| kona | ah, yeah, i think you're right. a few apps would definitely need a way to disable while active. | 08:15 |
| kona | the "recommended" method for using the device as a phone with the keyboard attached is with either a wired or bluetooth headset. | 08:16 |
| humpelstilzchen[ | problem is that you can't hide the keyboard once it is attached | 08:17 |
| kona | i don't know whether i could comfortably hold the phone to my ear with the keyboard attached, but i intend to use it more like an n810 wimax so i wasn't even thinking about calls. | 08:17 |
| humpelstilzchen[ | unlike the n900 with its slide. The PP hinge do support a max of 180°, so no turn around either | 08:17 |
| kona | right. | 08:18 |
| xmn | yeah. That my biggest issue with it actually. | 08:19 |
| kona | i made this contraption with a BT keyboard affixed into a foldable fabric case for my android phone and it is tolerable because i can fold it 360 degrees | 08:20 |
| xmn | I would use it in the case without headset on purpose... lol. But there will be times that you can't avoid it. | 08:20 |
| xmn | nice! | 08:20 |
| xmn | pictures? | 08:20 |
| kona | but with the pp kb, it's just clearly meant to be clamshell. | 08:20 |
| kona | uh, let me see. | 08:20 |
| xmn | yeah I was hoping it would be like those yoga/windows laptop flip devices. | 08:21 |
| humpelstilzchen[ | yoga, exactly. Also I would not mind to go without the extra battery | 08:22 |
| xmn | I think I may hold out for the vers 2 if when that comes. | 08:22 |
| xmn | I love the extra battery though. My n900 last all day ... not the PP yet | 08:22 |
| xmn | I would however love a mod that allow you to keep the phone back on while using the kb case | 08:23 |
| kona | xmn: https://rootaction.net/owncloud/index.php/s/r5sOFG9naYhiKX8 | 08:23 |
| xmn | Like having the if2 on the outiside ready for the kb case to use | 08:24 |
| kona | hopefully that link works to show my s10e with the rii keyboard. | 08:24 |
| xmn | dude, that a pretty cool mod and idea. kodos | 08:25 |
| xmn | and bonus point for using own/next cloud :) | 08:25 |
| kona | those are actually magnetic snaps rather than mechanical snaps. | 08:25 |
| kona | ty :) | 08:26 |
| kona | i must go find sleep now though. catch y'all later :) | 08:26 |
| xmn | coolio | 08:27 |
| xmn | have a good one. thx for the chat | 08:27 |
| freemangordon | Wizzup: did you try the new mce? | 09:19 |
| humpelstilzchen[ | Speaking of proximity sensor, looks like it is not configured on maemo, known todo item? | 09:56 |
| sicelo | In Leste? Device? | 10:34 |
| humpelstilzchen[ | pinephone | 10:35 |
| Wizzup | freemangordon: let me check, I tried the one with double press fixes and the race fix and it works fine | 11:12 |
| Wizzup | humpelstilzchen[: not sure if that is known wrt proximity | 11:13 |
| Wizzup | freemangordon: and yes, it was indeed showing a note | 11:27 |
| Wizzup | uvos: yeah pp keyboard is an always-attached one | 11:28 |
| uvos | Wizzup: right | 13:01 |
| uvos | Wizzup: needs support in mce, the assumption there is that if there is no keyboard switch, there is no keyboard | 13:01 |
| uvos | really it should check if there is a kbd | 13:01 |
| freemangordon | uvos: I tried to implement something like that back then and kind of failed: How do you check if there is a kbd? | 13:46 |
| freemangordon | do you assume that if you have 'qwerty' then you have a kbd? | 13:46 |
| freemangordon | what if it is 'явертъ'? or, do we have a list of scan codes that define kbd as kbd? | 13:47 |
| uvos | the kernel itself | 13:47 |
| uvos | has a list of scancodes it considers a keyboard | 13:47 |
| freemangordon | does it? | 13:47 |
| uvos | that is almost all <255 | 13:47 |
| uvos | freemangordon: yes | 13:48 |
| uvos | freemangordon: but only for internal use | 13:48 |
| uvos | freemangordon: its for the kernel console | 13:48 |
| uvos | i would do the same thing | 13:48 |
| uvos | acutally mce allready dose the same thing | 13:48 |
| uvos | its just not used in this way | 13:48 |
| freemangordon | as I said - I was about to do the same/similar thing, but at the end I thought it would be too hacky for may taste | 13:48 |
| uvos | right | 13:49 |
| uvos | but mce allready dose this | 13:49 |
| uvos | for the keyboard catigory | 13:49 |
| freemangordon | does it? where? | 13:49 |
| freemangordon | maybe I did it after all and forgot :) | 13:49 |
| uvos | no, i did | 13:50 |
| Wizzup | uvos: we mostly need to check how the kernel i2c implementation reports keyboard attached or not | 13:50 |
| uvos | Wizzup: why | 13:50 |
| uvos | Wizzup: its an evdev device no? | 13:50 |
| Wizzup | yes but if it does not report removal we have a problem | 13:50 |
| freemangordon | becasue this is deviice specific module I would say | 13:50 |
| Wizzup | I think re-recv used to set the keyboard attached property, but maybe that changed | 13:51 |
| Wizzup | (in gconf) | 13:51 |
| freemangordon | it does | 13:51 |
| freemangordon | iirc | 13:51 |
| uvos | sortof | 13:51 |
| uvos | so ke-recv also reports on the keyboard switch | 13:51 |
| Wizzup | yes | 13:51 |
| Wizzup | there is attached and slider state | 13:51 |
| uvos | so dose mce, mce also uses its information internally | 13:51 |
| uvos | anyhow | 13:52 |
| freemangordon | hmm... | 13:52 |
| uvos | its redundant implementation is what im saying | 13:52 |
| freemangordon | why shall we treat this keyboard diffferently then a BT keyboard? | 13:52 |
| uvos | why would we? | 13:52 |
| freemangordon | uvos: in mce, right? | 13:52 |
| freemangordon | because it was not there initially | 13:53 |
| uvos | it was | 13:53 |
| uvos | mce used to use a whitelist | 13:53 |
| uvos | to determine what is the keyboard | 13:53 |
| uvos | and uses the keyboard switch interally for lots of stull | 13:53 |
| uvos | *stuff | 13:53 |
| freemangordon | can we have device specific package? | 13:53 |
| uvos | we dont need it | 13:53 |
| uvos | "why shall we treat this keyboard diffferently then a BT keyboard?" | 13:54 |
| uvos | we would not | 13:54 |
| uvos | the problem right now | 13:54 |
| freemangordon | ok | 13:54 |
| uvos | is that mce on a device without a keyboard swich | 13:54 |
| uvos | will report the keyboard as closed at all times | 13:54 |
| uvos | this the vkb will show | 13:54 |
| uvos | and mce will change its behavior | 13:54 |
| uvos | falsely | 13:54 |
| uvos | same problem with ke-recv and its interface | 13:54 |
| uvos | altho i would recommend deprecating that | 13:55 |
| uvos | since its on gconf and redundant | 13:55 |
| uvos | https://github.com/maemo-leste/mce/blob/db0f5d0bb7671182f35bfa4728462ba2890c6fd0/src/utils/event-input.h#L52 | 13:55 |
| uvos | thats the whitelist | 13:55 |
| uvos | https://github.com/maemo-leste/mce/blob/db0f5d0bb7671182f35bfa4728462ba2890c6fd0/src/utils/event-input.h#L169 | 13:56 |
| freemangordon | uvos: that's why we need device specific package - to know which device has internal kbd and slider and to behave accordingly | 13:56 |
| uvos | thats the match rule i added | 13:56 |
| uvos | note that these are keycodes | 13:56 |
| uvos | not keysymbs | 13:56 |
| uvos | this means that KEY_Q is not nesscarly a Q | 13:56 |
| uvos | depending on layout | 13:56 |
| freemangordon | yeah, sure | 13:56 |
| freemangordon | so, if a device have any of those it is a kbd? | 13:57 |
| uvos | freemangordon: no we dont | 13:57 |
| uvos | @ device specific package | 13:57 |
| uvos | the device has a silder if it has a event device that advertises the slider key | 13:57 |
| uvos | and it has a keyboard if it has a device that maches that rule | 13:58 |
| freemangordon | I would love if we don;t need, but don;t really see how we'll make it run properly otherwise | 13:58 |
| uvos | we dont | 13:58 |
| freemangordon | ah, it is again that libinput migration, no? | 13:58 |
| uvos | wel libinput dose this allready | 13:58 |
| uvos | but you could do the same thing with this code too | 13:58 |
| uvos | point is that kernel gives all the information needed | 13:58 |
| freemangordon | ok | 13:58 |
| freemangordon | I need to look in the code to grok what you;re saying I guess | 13:59 |
| freemangordon | uvos: so, basically the idea is: we enum all the input devices and, if a device have KEY_Q (or some of the others), then it is a kbd, if a device advertises slider then it is a slider etc, correct? | 14:01 |
| uvos | not quite | 14:01 |
| uvos | but yes | 14:02 |
| uvos | except you throw all devices into one pool | 14:02 |
| freemangordon | and combine the caps? | 14:02 |
| Wizzup | Does that mean we need to keep many devices open? | 14:02 |
| freemangordon | I think we do it either ways | 14:02 |
| uvos | if across all devices we have a qwerty layout we have a keyboard | 14:02 |
| uvos | we do | 14:02 |
| uvos | and kernel dose internaly anyhow | 14:02 |
| uvos | (for keyboards) | 14:02 |
| uvos | (any device matched as (part of) a keyboard will be kept open indefinatly by the kernel in all cases) | 14:03 |
| uvos | for sysrq and fbcon | 14:03 |
| freemangordon | ok, so if we close the slider and have BT kbd attached, then pressing on an input field will bring vkb up, no? | 14:03 |
| uvos | yeah, i gues we could count caps | 14:04 |
| uvos | so if we have every qwery key twice | 14:04 |
| uvos | we assume only one is hidden | 14:04 |
| freemangordon | uhuh, this is even more hacky, but yeah, might work :) | 14:05 |
| freemangordon | I think I already implemented something like that in hulda | 14:05 |
| freemangordon | (ke-recv) | 14:05 |
| freemangordon | oh, hulda is not in ke-recv?!? | 14:08 |
| freemangordon | where was that? | 14:08 |
| Wizzup | there is ke-recv-extra | 14:08 |
| freemangordon | yeah | 14:08 |
| freemangordon | yeah, this :) https://github.com/maemo-leste/ke-recv-extra/commit/e10952c191a159cbea8b9c4059251a29ee814e68 | 14:09 |
| uvos | regarding the pp keyboard and monitoring its detachment | 14:09 |
| freemangordon | uvos: see ^^^ | 14:09 |
| uvos | if deaching it dosent remove the evdev interface | 14:09 |
| uvos | its just broken | 14:09 |
| uvos | hacking around that in mce is not sane | 14:09 |
| uvos | fix the kernel | 14:10 |
| freemangordon | agree | 14:10 |
| freemangordon | uvos: so, I am looking for KEY_ENTER and KEY_ESC to decide this is a kbd | 14:10 |
| uvos | well phone kbds rarely have esc | 14:11 |
| uvos | also i dont want to match specifc devices at all | 14:11 |
| uvos | a keyboard might be implemented across several devices | 14:11 |
| uvos | (as is sorta the case on d4) | 14:11 |
| uvos | i rather do what the kernel dose | 14:11 |
| freemangordon | ok, but see the commit description | 14:11 |
| freemangordon | basically the same what you said | 14:12 |
| uvos | right | 14:12 |
| uvos | yeah | 14:12 |
| uvos | that part yes | 14:12 |
| tmlind | freemangordon: for the gnss MPDTIME, in theory kernel should provide ktime_get_clocktai() | 14:12 |
| tmlind | in practise i did not get it to work and it's the same as ktime_get_rtc() | 14:12 |
| tmlind | sorry i mean ktime_get_real() | 14:13 |
| tmlind | not sure if anything needs to be done for userspace, i guess we'll find out when we have the faster gnss fix working | 14:14 |
| freemangordon | tmlind: honestly, I know none of those 2 functions, the point is that libtime supports "operator time", which can be set by a daemon. so, my point was - if you are going to somehow get some GPS time and provide it to userspace, please consider libtime :) | 14:15 |
| tmlind | freemangordon: ok not planning to do that right now | 14:15 |
| uvos | besides the gps driver would just provide a rtc interface no? | 14:16 |
| freemangordon | I think we will have issues if kernel sets the time behind our back, but that might be just me not knowing how it works | 14:16 |
| uvos | it would just provide another rtc | 14:16 |
| uvos | how that affects system time is userspaces problem | 14:16 |
| freemangordon | uvos: who is going to read that? and how we know which one is correct? | 14:16 |
| uvos | some deamon we write :P | 14:16 |
| freemangordon | like - a person with 2 watches never knows the time :) | 14:16 |
| tmlind | yeah we could implement a serdev ppt device when gnss fix is available | 14:16 |
| freemangordon | uvos: exactly ;) | 14:17 |
| freemangordon | so, please consider libtime when we writing the daemon :p | 14:17 |
| tmlind | sorry ptp device | 14:17 |
| freemangordon | whoever 'we' is | 14:17 |
| freemangordon | otherwise all the alarms and stuff will simply stop work | 14:18 |
| uvos | right point is the kernel never sets the time behind our back | 14:18 |
| freemangordon | great | 14:18 |
| tmlind | well a ptp device can be configured as an input for chrony | 14:18 |
| freemangordon | we already have clockd | 14:18 |
| freemangordon | no need doe yet another daemon | 14:18 |
| freemangordon | *for yet | 14:18 |
| tmlind | no need to do anything as ntp takes care of things for us | 14:19 |
| uvos | well considering if we need clockd is ofc on the table to | 14:19 |
| freemangordon | sure we do | 14:19 |
| uvos | not really | 14:19 |
| freemangordon | we don;t have the resources to rewrite half of the systems | 14:19 |
| freemangordon | well, maybe in some other distro there is no need | 14:19 |
| tmlind | well chrony is already configured and running for ntp, right? | 14:19 |
| uvos | no | 14:20 |
| freemangordon | I have to check what clockd does in case ntp sets the time | 14:20 |
| tmlind | oh right, did we used to have chrony by default? | 14:20 |
| uvos | no i dont think so | 14:21 |
| tmlind | kind of remember ntp causing some pm issues a few years ago | 14:21 |
| uvos | there is a script that updates time from ntp | 14:21 |
| uvos | on wifi conecct | 14:21 |
| uvos | or something silly like that | 14:21 |
| uvos | it rarely works for me | 14:21 |
| tmlind | heh ok | 14:21 |
| uvos | ntpd causes pm issues yes | 14:21 |
| tmlind | i think chrony got those fixed, busybox ntpd never had issues with pm | 14:22 |
| Wizzup | yes, it runs on network connection (which does not seem silly to me), but it requires dns to work and doesn't work on v6 | 14:22 |
| tmlind | the operator time can be off by hours easily depending on the operator | 14:22 |
| freemangordon | yet another reason we shall think a bit before removing maemo daemons in favor of upstream one | 14:22 |
| freemangordon | tmlind: how's that? | 14:23 |
| Wizzup | it's not a maemo daemon but yeah | 14:23 |
| freemangordon | Wizzup: in principle tha is | 14:23 |
| freemangordon | all maemo stuff was done with battery in mind | 14:23 |
| tmlind | freemangordon: have you not travelled with the automatic operator time configured for the phone and noticed how it's often totally off by some random time? | 14:23 |
| uvos | this is true | 14:23 |
| Wizzup | also ntp is complicated if you want to actually protect against attacks | 14:23 |
| freemangordon | I have always had that disabled | 14:24 |
| Wizzup | I don't think we use operator provided ntp servers | 14:24 |
| uvos | i have seen operators lag several minutes | 14:24 |
| freemangordon | because it was working with none of the operators here for me :) | 14:24 |
| r3boot | Dont know if its viable for maemo, but chrony is a lot better then plain ntpd when it comes to ACLs | 14:24 |
| freemangordon | I would rather teach clock | 14:25 |
| freemangordon | *clockd | 14:25 |
| freemangordon | to use more sources than needed | 14:25 |
| freemangordon | *if needed | 14:25 |
| tmlind | yeah so the ideal situation would be some lightweight ntp server configured in a pm friendly way and clockd just uses kernel time. then any additional time sources can be configured for the ntp server as needed | 14:25 |
| freemangordon | tmlind: https://github.com/maemo-leste/clockd/blob/master/clockd/rclockd.c#L58 | 14:26 |
| Wizzup | tmlind: there are other ways to get time, through https for example, to attempt to prevent against some attacks | 14:27 |
| freemangordon | what I don;t understand is: how we knoe | 14:27 |
| freemangordon | *know which rtc is the correct one if we have more than one? | 14:27 |
| Wizzup | there is also gps | 14:28 |
| Wizzup | well I guess were talking about that :) | 14:28 |
| freemangordon | yeah | 14:28 |
| uvos | you just need enogh rtcs/time sources then they can vote xD | 14:28 |
| freemangordon | so, if we have /dev/rtc and /dev/rtc1, how do we know which one is the correct one? | 14:28 |
| Wizzup | http://phk.freebsd.dk/time/20151129/ | 14:28 |
| freemangordon | uvos: :D | 14:28 |
| freemangordon | you needs at least 3 | 14:29 |
| humpelstilzchen[ | shouldn't /dev/rtc just be a symlink? | 14:29 |
| freemangordon | still | 14:29 |
| freemangordon | we have omap rtc | 14:29 |
| freemangordon | and if gps interface provides yet another rtc | 14:29 |
| freemangordon | which one shall we prefer? | 14:29 |
| tmlind | no, a ptp device | 14:29 |
| tmlind | see drivers/ptp | 14:30 |
| tmlind | and we don't have a driver for that yet | 14:30 |
| freemangordon | ok | 14:30 |
| freemangordon | anyway, work mtg, ttyl | 14:30 |
| tmlind | but seems like it should be easy to do with unknown jitter with the serial port commands :) | 14:30 |
| tmlind | as i think we only get the time every second | 14:30 |
| tmlind | so to me it seems timed can just use ktime_get_real() with chrony configured and that's all we need | 14:31 |
| tmlind | seems like timed just needs to update the rtc as needed for alarms etc with hwclock command | 14:33 |
| tmlind | actually timed needs to use the timex.h api, ktime_get_real() is a kernel interface.. | 14:34 |
| uvos | Wizzup: parazyd: looks like irc.txt has been broken again since yesterday] | 16:33 |
| Wizzup | u will try to fix it during parazyds absence | 17:08 |
| Wizzup | uvos: | 17:08 |
| kona | uvos: not sure if you saw, i dug through the pinephone kbd schematic, there's no sensor for the hinge. | 17:58 |
| kona | but a lot of things could be done in i2c-inputd or from discussion last night, maybe the prox sensor to detect if kbd is both present and open, and there's a separate button on the kbd that can detect long press, short press, double press, and not pressed, distinct from the phone power button. | 17:59 |
| uvos | kona: yeah i sa | 18:02 |
| uvos | w | 18:02 |
| uvos | i gues its not so important for us to know if the keyboard is open since its a clamshell | 18:03 |
| uvos | would have been good to lock on close or something, but thats ok | 18:03 |
| uvos | useing the proximitry sensor for that is not acceptable | 18:04 |
| uvos | the device would lock or whaetver just from the user holding it wrong | 18:04 |
| uvos | we are not apple | 18:04 |
| kona | maybe keyboard_installed && prox_sensor_go_brr ? | 18:05 |
| kona | it's prohibitively awkward to hold the phone to one's ear with kbd installed. | 18:06 |
| uvos | no, even then accidentaly locking the deivce by covering the sensor is easy | 18:06 |
| kona | could also be an option in settings / screen lock. | 18:06 |
| kona | given how often my android prox sensor tricks in low lighting conditions, i agree. | 18:06 |
| kona | s/ick/ip/ | 18:07 |
| Wizzup | uvos: should be back | 18:42 |
| uvos | lorem ipsum dolor sit amet | 18:51 |
| uvos | Wizzup: nope | 18:51 |
| Wizzup | hmm | 18:52 |
| sicelo | nowadays my droid 4 is always guaranteed to not connect to wifi on first try | 19:32 |
| freemangordon | sicelo: same here | 19:33 |
| uvos | its deff buggy | 19:38 |
| uvos | makeing it loose conection by walking away often hangs the kernel | 19:38 |
| uvos | unfortionatly no output | 19:38 |
| sicelo | this is before even connecting, so i haven't 'lost' connection by then | 19:49 |
| uvos | sortof | 19:50 |
| uvos | the conection fails to happen once | 19:50 |
| uvos | and then the kernel module is in a bad state | 19:50 |
| uvos | i have this happen and then i cant connect untill i reprobe the module | 19:50 |
| uvos | sometimes it hangs | 19:50 |
| uvos | etc | 19:50 |
| uvos | its porbubly just one bug | 19:51 |
| Wizzup | sicelo: always on first try? hmmmm | 20:19 |
| inky | not sure what i am saying is helpful, but i was running openntpd (from openbsd project) on nokia devices. i don't know if it interfers with calls though because i don't make or receive 'calls'. | 23:40 |
| Wizzup | openntpd kills battery in my experience | 23:53 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!