<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.
uvos has quit [Ping timeout: 250 seconds]
_inky has quit [Ping timeout: 245 seconds]
<kona>
def dont
<kona>
that will likely fry something
<kona>
kbd takes some fiddling to get working on mobian but it does work.
<kona>
activation distance is a bit unforgiving, which leaves the keyboard feeling mushy and unresponsive, but eliminates some unintentional keypresses
uvos has joined #maemo-leste
<kona>
phone fits in it very well, and it feels solid once assembled
<kona>
hinge is stiff, which is good for mobile use but might give trouble for people with grip issues
<uvos>
is there a hw way to dect if its closed?
<huckg>
uvos: Thanks for the help yesterday with bionic audio, I boosted the volume by editing HiFi.conf. 5 was really very quiet.
_inky has joined #maemo-leste
<kona>
uvos: not sure, just got it
uvos has quit [Read error: Connection reset by peer]
<kona>
no, pp hwkbd schematic shows no hinge sensor
_inky has joined #maemo-leste
_inky has quit [Ping timeout: 256 seconds]
_inky has joined #maemo-leste
_inky has quit [Ping timeout: 250 seconds]
joerg has quit [Ping timeout: 250 seconds]
macros_ has quit [Ping timeout: 250 seconds]
macros__ has joined #maemo-leste
joerg has joined #maemo-leste
_inky has joined #maemo-leste
mardy has joined #maemo-leste
RedM_ has joined #maemo-leste
jrayhawk_ has joined #maemo-leste
vectis_ has joined #maemo-leste
The_Niz has joined #maemo-leste
mardy has quit [*.net *.split]
Langoor has quit [*.net *.split]
freemangordon has quit [*.net *.split]
amk has quit [*.net *.split]
RedW has quit [*.net *.split]
sixwheeledbeast has quit [*.net *.split]
vectis has quit [*.net *.split]
jrayhawk has quit [*.net *.split]
The_Niz_ has quit [*.net *.split]
dsc_ has quit [*.net *.split]
lel has quit [*.net *.split]
amk has joined #maemo-leste
mardy has joined #maemo-leste
Langoor has joined #maemo-leste
sixwheeledbeast has joined #maemo-leste
dsc_ has joined #maemo-leste
freemangordon has joined #maemo-leste
<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.
<xmn>
btw, kona I forget it does have backlighting right? Are you happy so far with it?
<humpelstilzchen[>
I would have thought of the proximity sensor for keyboard detection, but maybe use proximity and IMU
<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)
<kona>
prox sensor might be a way to do it.
<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.
<xmn>
ah, yeah forgot about the prox! maybe combine with the accelerometer
<xmn>
would be nice to turn off keyboard keystroke when using certain apps like the phone apps
<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
<kona>
firmware is totally open, and gets loaded as far as i can see by the drivers.
<xmn>
yeah you would need a profile for speed likely or something. I'm no dev :P
<kona>
so there's a bunch of customizations we could do.
<xmn>
yeah hopefully in a years time we have lots of options
<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.
<xmn>
hmm, interesting idea
<kona>
and could also mod the daemon to activate and deactivate OSK
<xmn>
so you could basic block the polling when using the phone apps etc
<kona>
based on button presses
<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
<xmn>
I'm*
<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.
<kona>
ah, yeah, i think you're right. a few apps would definitely need a way to disable while active.
<kona>
the "recommended" method for using the device as a phone with the keyboard attached is with either a wired or bluetooth headset.
<humpelstilzchen[>
problem is that you can't hide the keyboard once it is attached
<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.
<humpelstilzchen[>
unlike the n900 with its slide. The PP hinge do support a max of 180°, so no turn around either
<kona>
right.
<xmn>
yeah. That my biggest issue with it actually.
<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
<xmn>
I would use it in the case without headset on purpose... lol. But there will be times that you can't avoid it.
<xmn>
nice!
<xmn>
pictures?
<kona>
but with the pp kb, it's just clearly meant to be clamshell.
<kona>
uh, let me see.
<xmn>
yeah I was hoping it would be like those yoga/windows laptop flip devices.
<humpelstilzchen[>
yoga, exactly. Also I would not mind to go without the extra battery
<xmn>
I think I may hold out for the vers 2 if when that comes.
<xmn>
I love the extra battery though. My n900 last all day ... not the PP yet
<xmn>
I would however love a mod that allow you to keep the phone back on while using the kb case
<freemangordon>
uvos: that's why we need device specific package - to know which device has internal kbd and slider and to behave accordingly
<uvos>
thats the match rule i added
<uvos>
note that these are keycodes
<uvos>
not keysymbs
<uvos>
this means that KEY_Q is not nesscarly a Q
<uvos>
depending on layout
<freemangordon>
yeah, sure
<freemangordon>
so, if a device have any of those it is a kbd?
<uvos>
freemangordon: no we dont
<uvos>
@ device specific package
<uvos>
the device has a silder if it has a event device that advertises the slider key
<uvos>
and it has a keyboard if it has a device that maches that rule
<freemangordon>
I would love if we don;t need, but don;t really see how we'll make it run properly otherwise
<uvos>
we dont
<freemangordon>
ah, it is again that libinput migration, no?
<uvos>
wel libinput dose this allready
<uvos>
but you could do the same thing with this code too
<uvos>
point is that kernel gives all the information needed
<freemangordon>
ok
<freemangordon>
I need to look in the code to grok what you;re saying I guess
inky has joined #maemo-leste
<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?
<uvos>
not quite
<uvos>
but yes
<uvos>
except you throw all devices into one pool
<freemangordon>
and combine the caps?
<Wizzup>
Does that mean we need to keep many devices open?
<freemangordon>
I think we do it either ways
<uvos>
if across all devices we have a qwerty layout we have a keyboard
<uvos>
we do
<uvos>
and kernel dose internaly anyhow
<uvos>
(for keyboards)
inky_ has quit [Ping timeout: 252 seconds]
<uvos>
(any device matched as (part of) a keyboard will be kept open indefinatly by the kernel in all cases)
<uvos>
for sysrq and fbcon
<freemangordon>
ok, so if we close the slider and have BT kbd attached, then pressing on an input field will bring vkb up, no?
<uvos>
yeah, i gues we could count caps
<uvos>
so if we have every qwery key twice
<uvos>
we assume only one is hidden
<freemangordon>
uhuh, this is even more hacky, but yeah, might work :)
rafael2k has joined #maemo-leste
<freemangordon>
I think I already implemented something like that in hulda
<uvos>
regarding the pp keyboard and monitoring its detachment
<freemangordon>
uvos: see ^^^
<uvos>
if deaching it dosent remove the evdev interface
<uvos>
its just broken
<uvos>
hacking around that in mce is not sane
<uvos>
fix the kernel
<freemangordon>
agree
<freemangordon>
uvos: so, I am looking for KEY_ENTER and KEY_ESC to decide this is a kbd
<uvos>
well phone kbds rarely have esc
<uvos>
also i dont want to match specifc devices at all
<uvos>
a keyboard might be implemented across several devices
<uvos>
(as is sorta the case on d4)
<uvos>
i rather do what the kernel dose
<freemangordon>
ok, but see the commit description
<freemangordon>
basically the same what you said
<uvos>
right
<uvos>
yeah
<uvos>
that part yes
<tmlind>
freemangordon: for the gnss MPDTIME, in theory kernel should provide ktime_get_clocktai()
<tmlind>
in practise i did not get it to work and it's the same as ktime_get_rtc()
<tmlind>
sorry i mean ktime_get_real()
Guest84 has joined #maemo-leste
<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
Guest84 has quit [Client Quit]
<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 :)
<tmlind>
freemangordon: ok not planning to do that right now
<uvos>
besides the gps driver would just provide a rtc interface no?
<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
<uvos>
it would just provide another rtc
<uvos>
how that affects system time is userspaces problem
<freemangordon>
uvos: who is going to read that? and how we know which one is correct?
<uvos>
some deamon we write :P
<freemangordon>
like - a person with 2 watches never knows the time :)
<tmlind>
yeah we could implement a serdev ppt device when gnss fix is available
<freemangordon>
uvos: exactly ;)
<freemangordon>
so, please consider libtime when we writing the daemon :p
<tmlind>
sorry ptp device
<freemangordon>
whoever 'we' is
<freemangordon>
otherwise all the alarms and stuff will simply stop work
<uvos>
right point is the kernel never sets the time behind our back
<freemangordon>
great
<tmlind>
well a ptp device can be configured as an input for chrony
<freemangordon>
we already have clockd
<freemangordon>
no need doe yet another daemon
<freemangordon>
*for yet
<tmlind>
no need to do anything as ntp takes care of things for us
<uvos>
well considering if we need clockd is ofc on the table to
<freemangordon>
sure we do
<uvos>
not really
<freemangordon>
we don;t have the resources to rewrite half of the systems
<freemangordon>
well, maybe in some other distro there is no need
<tmlind>
well chrony is already configured and running for ntp, right?
<uvos>
no
<freemangordon>
I have to check what clockd does in case ntp sets the time
<tmlind>
oh right, did we used to have chrony by default?
<uvos>
no i dont think so
<tmlind>
kind of remember ntp causing some pm issues a few years ago
<uvos>
there is a script that updates time from ntp
<uvos>
on wifi conecct
<uvos>
or something silly like that
<uvos>
it rarely works for me
<tmlind>
heh ok
<uvos>
ntpd causes pm issues yes
<tmlind>
i think chrony got those fixed, busybox ntpd never had issues with pm
<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
<tmlind>
the operator time can be off by hours easily depending on the operator
<freemangordon>
yet another reason we shall think a bit before removing maemo daemons in favor of upstream one
<freemangordon>
tmlind: how's that?
<Wizzup>
it's not a maemo daemon but yeah
<freemangordon>
Wizzup: in principle tha is
<freemangordon>
all maemo stuff was done with battery in mind
<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?
<uvos>
this is true
<Wizzup>
also ntp is complicated if you want to actually protect against attacks
<freemangordon>
I have always had that disabled
<Wizzup>
I don't think we use operator provided ntp servers
<uvos>
i have seen operators lag several minutes
<freemangordon>
because it was working with none of the operators here for me :)
<r3boot>
Dont know if its viable for maemo, but chrony is a lot better then plain ntpd when it comes to ACLs
<freemangordon>
I would rather teach clock
<freemangordon>
*clockd
<freemangordon>
to use more sources than needed
<freemangordon>
*if needed
<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
<humpelstilzchen[>
shouldn't /dev/rtc just be a symlink?
<freemangordon>
still
<freemangordon>
we have omap rtc
<freemangordon>
and if gps interface provides yet another rtc
<freemangordon>
which one shall we prefer?
<tmlind>
no, a ptp device
<tmlind>
see drivers/ptp
<tmlind>
and we don't have a driver for that yet
<freemangordon>
ok
<freemangordon>
anyway, work mtg, ttyl
<tmlind>
but seems like it should be easy to do with unknown jitter with the serial port commands :)
<tmlind>
as i think we only get the time every second
<tmlind>
so to me it seems timed can just use ktime_get_real() with chrony configured and that's all we need
<tmlind>
seems like timed just needs to update the rtc as needed for alarms etc with hwclock command
<tmlind>
actually timed needs to use the timex.h api, ktime_get_real() is a kernel interface..
pere has quit [Ping timeout: 250 seconds]
uvos has quit [Ping timeout: 256 seconds]
inky has quit [Ping timeout: 256 seconds]
inky has joined #maemo-leste
marabej has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
Wizzup: parazyd: looks like irc.txt has been broken again since yesterday]
pere has joined #maemo-leste
marabej has quit [Quit: Leaving]
<Wizzup>
u will try to fix it during parazyds absence
<Wizzup>
uvos:
rafael2k has quit [Ping timeout: 245 seconds]
rafael2k has joined #maemo-leste
<kona>
uvos: not sure if you saw, i dug through the pinephone kbd schematic, there's no sensor for the hinge.
<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.
<uvos>
kona: yeah i sa
<uvos>
w
<uvos>
i gues its not so important for us to know if the keyboard is open since its a clamshell
<uvos>
would have been good to lock on close or something, but thats ok
<uvos>
useing the proximitry sensor for that is not acceptable
<uvos>
the device would lock or whaetver just from the user holding it wrong
<kona>
it's prohibitively awkward to hold the phone to one's ear with kbd installed.
<uvos>
no, even then accidentaly locking the deivce by covering the sensor is easy
<kona>
could also be an option in settings / screen lock.
<kona>
given how often my android prox sensor tricks in low lighting conditions, i agree.
<kona>
s/ick/ip/
Pali has quit [Quit: Pali]
lel has joined #maemo-leste
<Wizzup>
uvos: should be back
<uvos>
lorem ipsum dolor sit amet
<uvos>
Wizzup: nope
<Wizzup>
hmm
lel has quit [Remote host closed the connection]
lel has joined #maemo-leste
Oksanaa has quit [Ping timeout: 240 seconds]
<sicelo>
nowadays my droid 4 is always guaranteed to not connect to wifi on first try
<freemangordon>
sicelo: same here
<uvos>
its deff buggy
<uvos>
makeing it loose conection by walking away often hangs the kernel
<uvos>
unfortionatly no output
<sicelo>
this is before even connecting, so i haven't 'lost' connection by then
<uvos>
sortof
<uvos>
the conection fails to happen once
<uvos>
and then the kernel module is in a bad state
<uvos>
i have this happen and then i cant connect untill i reprobe the module
<uvos>
sometimes it hangs
<uvos>
etc
<uvos>
its porbubly just one bug
blasty_ has quit [Ping timeout: 256 seconds]
sicelo has quit [Ping timeout: 256 seconds]
StephanvanSchaik has quit [Ping timeout: 256 seconds]
blasty has joined #maemo-leste
StephanvanSchaik has joined #maemo-leste
sicelo has joined #maemo-leste
sicelo has quit [Changing host]
sicelo has joined #maemo-leste
bencoh has quit [Ping timeout: 256 seconds]
bencoh has joined #maemo-leste
<Wizzup>
sicelo: always on first try? hmmmm
rafael2k has quit [Ping timeout: 250 seconds]
huckg has joined #maemo-leste
Daanct12 has joined #maemo-leste
Danct12 has quit [Ping timeout: 250 seconds]
inky has quit [Ping timeout: 256 seconds]
huckg has quit [Quit: Client closed]
inky has joined #maemo-leste
<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'.
<Wizzup>
openntpd kills battery in my experience
elastic_1 has quit [Quit: elastic_1]
elastic_dog has joined #maemo-leste
uvos has quit [Remote host closed the connection]
<kona>
i misread that to be an implementation of nntpd and wondered _why_ but now i see it's a time sync daemon.