goiken_ has quit [Ping timeout: 252 seconds]
goiken_ has joined #neo900
SylvieLorxu has quit [Quit: ZNC - http://znc.in]
goiken_ has quit [Ping timeout: 258 seconds]
goiken_ has joined #neo900
chomwitt has joined #neo900
goiken_ has quit [Ping timeout: 258 seconds]
goiken_ has joined #neo900
goiken_ has quit [Ping timeout: 240 seconds]
goiken_ has joined #neo900
ravelo has quit [Ping timeout: 260 seconds]
ravelo has joined #neo900
ravelo has quit [Disconnected by services]
liteIRC_ has joined #neo900
liteIRC_ is now known as liteIRC__
liteIRC__ is now known as ravelo
herpderphurr has joined #neo900
goiken_ has quit [Ping timeout: 265 seconds]
goiken_ has joined #neo900
Oksana has quit [Read error: Connection reset by peer]
Airwave has quit [Ping timeout: 244 seconds]
Oksana has joined #neo900
goiken_ has quit [Ping timeout: 244 seconds]
goiken_ has joined #neo900
galiven__ has joined #neo900
galiven_ has quit [Read error: Connection reset by peer]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #neo900
tsuggs has quit [Ping timeout: 265 seconds]
xman has quit [Quit: Leaving.]
goiken_ has quit [Ping timeout: 252 seconds]
goiken_ has joined #neo900
ecloud is now known as ecloud_wfh
pagurus` has joined #neo900
pagurus has quit [Ping timeout: 276 seconds]
goiken_ has quit [Ping timeout: 244 seconds]
goiken_ has joined #neo900
ravelo has quit [Disconnected by services]
liteIRC_ has joined #neo900
liteIRC_ is now known as liteIRC__
liteIRC__ is now known as ravelo
herpderphurr has quit [Ping timeout: 258 seconds]
goiken_ has quit [Ping timeout: 244 seconds]
goiken_ has joined #neo900
goiken_ has quit [Ping timeout: 250 seconds]
goiken_ has joined #neo900
ecloud_wfh has quit [Quit: No Ping reply in 180 seconds.]
ecloud has joined #neo900
brolin_empey has quit [Ping timeout: 276 seconds]
brolin_empey has joined #neo900
chomwitt has quit [Ping timeout: 240 seconds]
goiken_ has quit [Ping timeout: 265 seconds]
goiken_ has joined #neo900
goiken_ has quit [Ping timeout: 264 seconds]
goiken_ has joined #neo900
ravelo has quit [Quit: liteIRC for Android]
goiken_ has quit [Ping timeout: 264 seconds]
goiken_ has joined #neo900
chomwitt has joined #neo900
radekp has joined #neo900
SylvieLorxu has joined #neo900
paulk-collins has joined #neo900
galiven__ has quit [Ping timeout: 240 seconds]
galiven__ has joined #neo900
<atk> DocScrutinizer05: You know the proximity sensor on the N900? Will the Neo900 use the same sensor?
<atk> Has someone worked out how to "fix" it so that it doesn't get a false positive proximity response when in sunlight / bright light?
<DocScrutinizer05> well, as long as we can source the slider mech with flex cable, yes
<atk> Because personally I think the solution would be quite simple, but I have no idea how much control the Neo900 will have over the sensor.
<atk> I presume the sensor is just an IR led and a IR receiver?
<DocScrutinizer05> it's an integrated module consisting of IR LED, sensor, and controller, yes
<atk> controller?
<DocScrutinizer05> sure
<atk> What does this controller do?
<DocScrutinizer05> it pulses
<atk> ah, is there any way to get the output of the sensor without pulsing the led?
<DocScrutinizer05> hm?
<DocScrutinizer05> the sensor has a VCC, GND, and a logical output line
<DocScrutinizer05> btw the cam door uses basically same sensor
<atk> (this would be the obvious solution, if the sensor detects light without the led being on, it means that the sensor is obviously not in close proximity to anything, if the sensor doesn't detect light then the secondary test (blink + detect) would check if the device was simply in a dark area and not in proximity to anything.
<DocScrutinizer05> the controller is supposed to detect the signal generated by the LED pulse
<atk> ah, so the whole sensor is one integrated thing with just VCC, GND, and output?
<DocScrutinizer05> ambient light shouldn't matter
<DocScrutinizer05> yes
<atk> but the N900 does apparently have an issue (I've noticed this) with the device receiving calls in bright light / sunlight.
<atk> The device will lock the screen
<DocScrutinizer05> don't you think the screen simply disables backlight?
<atk> That's the ambient light sensor.
<atk> I mean the sensor to detect when someone has placed the device against their ear (to prevent their face touching buttons)
<atk> Hmm. I guess this does mean that it might be possible to fix this problem another way - combine the ambient light sensor and the proximity sensor, if the ambient light sensor can sense a lot of light but the prox sensor senses proximity, then the device is just in bright light (overwhelming the prox sensor)
galiven has joined #neo900
<DocScrutinizer05> the ambient light sensor switches off screen backlight with sufficient ambient brightness
<DocScrutinizer05> you easily could see this a s locked screen
<DocScrutinizer05> sorry
<atk> (the lights at my workplace trigger this bug)
<DocScrutinizer05> I only consider something a bug when I verified it by commandline means
galiven__ has quit [Ping timeout: 260 seconds]
<atk> As in, it is well known that this happened with N900 for some people in some scenarios (outdoors / odd lighting)
<atk> the prox sensor does have "high ambient light suppression" which works perfectly fine 99% of the time for me, but it has happened that I could not pick up a call on the device without using the slider when in specific lighting conditions / outside on a really sunny day.
<DocScrutinizer05> hmm
<atk> If you know how I can get the output of the prox sensor via command line, I could try it out for you at various places.
<DocScrutinizer05> watch cat /sys/devices/platform/gpio-switch/proximity/state
<DocScrutinizer05> watch -n 1 cat /sys/devices/platform/gpio-switch/proximity/state
<atk> (using the soft keyboard for the terminal is a flash back to days of android :( )
<DocScrutinizer05> you found the SFH7741 datasheet link in our block diagram?
<atk> Yeah
<atk> It appears that I can get it to happen very randomly if I get relatively close to a energy saving (fluorescent) lightbulb.
<atk> The ones at work are fluoros so I will check there when I get back on Monday.
<atk> I'll also try outside on a sunny day.
<atk> But I can't get it to give me a false positive with my halogen lightbulb.
arcean has joined #neo900
<DocScrutinizer05> which is weird since it's (supposed to be) sensitive to IR only, and incandescent has more IR than any flourescent lamp. But what just occurs to me: FL have fast pulses that might occasionally fall in sync freq (by a multiple) with the sensor pulses, so sensor thinks the pulse it sees is an echo of own LED
<atk> I just thought of that too.
chomwitt has quit [Ping timeout: 258 seconds]
<atk> Maybe I've just been unlucky :P
<atk> I bet the sensor uses the technique I described earlier too (check for light without pulse, check for light during pulse)
<DocScrutinizer05> yes, that's what I think it does
chomwitt has joined #neo900
<atk> I'll find a spare photo transistor and hook it up to my oscilloscope and do some tests to see what the light of the fluorescent lightbulb would look like to the device
<atk> as well as seeing the pulse frequency of the prox sensor
<DocScrutinizer05> :-)
<DocScrutinizer05> you can actually see the prox IR LED with several cameras
<atk> Yes, but it won't give you a good idea of the frequency
<DocScrutinizer05> possible fix: make ALS read out a current value whenever the prox goes open->closed
<DocScrutinizer05> only allow true "closed" when ALS doesn't say "bright"
<DocScrutinizer05> needs to check: how fast is ALS via /sys/ interface
<atk> Yeah, that's what I was saying earlier, it would avoid the 1/100 scenario where you can't pick up a call because the prox sensor thinks there's something close by.
<DocScrutinizer05> yep
<atk> In any case, I need to acquire some cow extract for my coffee.
<DocScrutinizer05> watch -n 1 cat /sys/class/i2c-adapter/i2c-2/2-0029/lux
<DocScrutinizer05> I think the lagginess of ALS is only by MCE poll interval
<DocScrutinizer05> since mce got RE'ed, you can patch it to fix the issue
<DocScrutinizer05> if that's even MCE that does screen lock on prox close
<DocScrutinizer05> IroN900:~# lsof |grep /sys/devices/platform/gpio-switch/proximity/state
<DocScrutinizer05> mce 815 root 18r REG 0,0 4096 4115 /sys/devices/platform/gpio-switch/proximity/state
<DocScrutinizer05> hald-addo 874 haldaemon 6r REG 0,0 4096 4115 /sys/devices/platform/gpio-switch/proximity/state
<DocScrutinizer05> what I'd love: pick up call by gesture - like: press cam button and shake
<DocScrutinizer05> or rather: hold device screen down, preass cam trigger, turn screen up (or into portrait orientation that's natural for listening to the phone)
<DocScrutinizer05> device already mutes ringtone when turning it screen down
<DocScrutinizer05> so screen-down, cam-trigger, !screen-down is a natural gesture for picking up a call
<atk> I like that these features were already being done in 2008 by nokia for the N900
<atk> but it's only recently that android phones get similar kinds of useful features
<DocScrutinizer05> meh andriod
<atk> it appears no android phone has yet mastered the ability of the N900 to be off but still be able to wake you up in the morning
<DocScrutinizer05> hahaha
<atk> Something I miss from android which the N900 doesn't do is the ability to use the volume rocker to fast forward / reverse songs and music when the device screen is locked.
<atk> If you hold down the volume up it skips to the next song
<atk> hold down and it goes to the beginning of the song, hold down again and it goes to the previous song
<atk> I wonder how hard it would be to get that working on the N900
<DocScrutinizer05> err N900 does this
<atk> It does?
<atk> :P
<DocScrutinizer05> needs "an app"
<DocScrutinizer05> easy to write yourself whatever you like, with dbus scripting
<atk> Hmm.
<atk> dbus in C is a pain
<atk> (If you avoid sd-bus and gdbus)
<atk> I plan on one day writing some simple generator for the silly amounts of boilerplate
<DocScrutinizer05> well, moderately easy. You still need the hildon-desktop hotkey feature
<atk> DocScrutinizer05: http://sprunge.us/RFSP
<atk> (This is calling a org.freedesktop.Notifications.Notify method)
<atk> (and there's no error checking on all the dbus_message_iter* calls (which return false if they run out of memory))
<atk> is this like the udev of dbus?
<atk> (sans the device node creation, I mean the scripting side :P)
<atk> Cool
<atk> I think I'll try hacking this together one day.
<atk> Amazing flexibility
<atk> Hmm, using the camera button would also be a nice feature for play pause.
<DocScrutinizer05> you see it's all there already, usually at least 80%
<atk> I also had this interesting idea of using espeak and some kind of audio ducking to say the current time out loud via the headphones when the camera button / some other button was pressed in a specific way
<DocScrutinizer05> hmm, 80% already there in "say who's calling"
<DocScrutinizer05> and again dbus-scripting
<atk> hmm
<atk> Well, I know what I'm doing during some future weekend.
<DocScrutinizer05> :-)
<DocScrutinizer05> actually for "say the time" I'd use a dbus-script that simply picks the right audio snippets to play back via aplay
<DocScrutinizer05> or playsound
<atk> I think for that I would go with python.
<DocScrutinizer05> case `date +hh:mm` in 00:*) playsound midnigt_and.wav;; 01:*) playsound one.wav;; ... esac;
<DocScrutinizer05> you can run python scripts too, as debus-script
<DocScrutinizer05> my payswoosh: http://paste.opensuse.org/44081634
<DocScrutinizer05> playswoosh even
<DocScrutinizer05> finding the parameters for /etc/dbus-scripts.d/dbus-scripts-settings took me half a day though, it's somewhat twisted
<DocScrutinizer05> and NEVER place the script into /etc/dbus-scripts.d/ ! it made the whole thing forkbomb ;-P
chomwitt has quit [Ping timeout: 240 seconds]
<DocScrutinizer05> iirc what took the most time though in finding the right parameters etfc, was to learn and to accept that freedesktop.org in their *eternal* wisdom specified the switches dbus signals in a way that doesn't tell whether the switch got closed or opened
<DocScrutinizer05> which makes me feel like grabbing the rifle and load it with owl shit
<atk> That EOMA68 device on crowd supply just got 10% funded in a day
<atk> I think they might make it: https://www.crowdsupply.com/eoma68/micro-desktop
<atk> It was at 80% yesterday afternoon.
<atk> Maybe it would be good PR for the Neo900 project if it publicly endorses the EOMA68 micro desktop
herpderphurr has joined #neo900
galiven_ has joined #neo900
galiven__ has joined #neo900
galiven_ has quit [Read error: Connection reset by peer]
galiven has quit [Ping timeout: 244 seconds]
ploop has quit [Ping timeout: 250 seconds]
ploop has joined #neo900
arcean has quit [Read error: Connection reset by peer]
radekp has quit [Quit: Konversation terminated!]
<wpwrak> good PR for devuan, for sure :)
drrrz has joined #neo900
MonkeyofDoom has joined #neo900
chomwitt has joined #neo900
paulk-collins has quit [Remote host closed the connection]
herpderphurr has quit [Ping timeout: 265 seconds]
<atk> Well, I got one, why not.
<atk> I then wrote an email to the FSF thanking them for bringing the device to my attention and asking them to take a look at the Neo900.
<atk> Just to see what the response will be, and to see if the FSF would be interested in helping Neo900 along in one way or another.
xman has joined #neo900
<atk> I think I'll send another email to the EFF at some point.
<DocScrutinizer05> fun observations? http://paste.opensuse.org/64720552
<atk> (I did of course make it clear that I am not part of the project but that you guys (or more specifically DocScrutinizer05) really liked the idea of me sending emails to these organisations asking for some guidance / help)
<atk> DocScrutinizer05: hah
<DocScrutinizer05> the oh-so-optimized journald is 10000 times slower than plain files
<atk> DocScrutinizer05: you know, you can get arch working without systemd :P
<MonkeyofDoom> journald is apocalyptically slow
* atk has his logs done by socklog for syslog and klog and all of that is done via svlogd from runit
* atk gets easy log rotation and nice text files out of it
<atk> When I get this device, I'll probably end up putting voidlinux on it, (I'll figure out how debian got their stuff to run so fast)
<atk> devuan*
<DocScrutinizer05> other fun observation: the devuan chroot nuked my suse system's cgroups so systemd-crond is not happy anymore (and probably no other login as well)
<DocScrutinizer05> http://paste.opensuse.org/49841194 http://susepaste.org/3918705 (line 165 more likely than from line 3)
<DocScrutinizer05> alas I have no clue how to cope with cgroups and systemd, to recover this without reboot to restart dang systemd
galiven has joined #neo900
<atk> why do you need crond?
<atk> or well, systemd-crond?
<DocScrutinizer05> well... there are a few tasks that ... meh you're kidding me
<DocScrutinizer05> you don't honestly ask why there are cronjobs on a system?
galiven__ has quit [Ping timeout: 244 seconds]
<atk> Well, why you can't replace systemd-crond with normal cron
<atk> And actually, I don't have any cronjobs on either this laptop or my server at all.
<DocScrutinizer05> will that change anything in the damn session management that systemd and freinds implement?
<atk> The server doesn't have any because they're don via systemd timers though, when I replace systemd with runit on the server, it will need cron
<atk> If you don't need session management you can literally do away with it.
<atk> No idea how easy your distribution will make that.
<atk> Might not work with a full DE, but works for a wm
<atk> There are replacements for systemd-logind too
<atk> and I don't quite see how session management relates to cron (user cronjobs?)
<DocScrutinizer05> prolly
<DocScrutinizer05> in /var/log/syslog I get periodic (every 15 min) http://paste.opensuse.org/33575402 systemd cgroup error
<atk> ah, it creates a session for root to run the cronjob
<atk> Yeah, with a normal cron you can just ignore all that
<atk> just replicate all these cronjobs with a normal cron (anacron for a pc) without using cgroups
<DocScrutinizer05> this all doesn't help me out, and I won't even try to start get rid of parts of systemd-madness in opensuse
<wpwrak> devuse ;-)
<wpwrak> or susian ?
<DocScrutinizer05> cgroups anybody?
<DocScrutinizer05> alas their introduction completely bypassed my attention
<DocScrutinizer05> *cough*
<wpwrak> you could design new ones, that depend on dbus, jQuery, mysql, and ASN.1. call them jgroups.
<DocScrutinizer05> saturn:/var/log # apropos cgroup
<DocScrutinizer05> cgroup: nothing appropriate.
<DocScrutinizer05> as embarrassing as it is, I seem to have to revert to aunt google and stuff like https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch01.html
paulk-nyan-big has joined #neo900
<DocScrutinizer05> anyway since I got fed up and I also learned a lot about lib/dependencies management during last 4 weeks, here it comes http://wstaw.org/m/2016/08/25/plasma-desktopvp2277.png genuine opensuse kicad. Now let's test this thing and see what we got there
<atk> wpwrak: that sounds like a series of great design decisions combined into a successful product.
<atk> wpwrak: You should pitch it to lennart.
<DocScrutinizer05> dang, opengl canvas doesn't work at all
<DocScrutinizer05> it shows existing tracks but doesn't draw anything new
<DocScrutinizer05> oops nope, that was cairo
Pali has joined #neo900
chomwitt has quit [Ping timeout: 240 seconds]
<DocScrutinizer05> so _maybe_ the solution to my cgroups-problems is not to run that chroot devuan kicad
<atk> hmm...
<atk> Oddly enough, the issue might be related.
<DocScrutinizer05> it for sure is
<atk> something to do with X, sessions and cgroupws
<atk> cgroups*
<DocScrutinizer05> http://paste.opensuse.org/49841194 http://susepaste.org/3918705 (line 165 more likely than from line 3)
<DocScrutinizer05> X?
<DocScrutinizer05> don't see that
<DocScrutinizer05> to me the most probably culprit is line165 in that syslog excerpt ^^^
<atk> X can run rootless with logind (session management magic) which might have something to do with opengl
<DocScrutinizer05> after that the next cronjob fails
<DocScrutinizer05> ooh, opengl, nah opengl is fine :-)
<DocScrutinizer05> it was cairo that doesn't work
<wpwrak> atk: the risk of doing so would be that he'd probably pick up some of these ideas :)
chomwitt has joined #neo900
paulk-nyan-big has quit [Quit: Leaving]
paulk-leonov has joined #neo900
chomwitt has quit [Ping timeout: 240 seconds]
Airwave has joined #neo900
xman has quit [Quit: Leaving.]
fling has quit [Ping timeout: 244 seconds]
goiken- has joined #neo900
goiken_ has quit [Ping timeout: 265 seconds]
paulk-leonov has quit [Remote host closed the connection]
Airwave has quit [Ping timeout: 240 seconds]
<DocScrutinizer05> sorry?
<DocScrutinizer05> oh, he as in The Poettering
<DocScrutinizer05> cgroups however are a kernel concept, just hihacked by Poettering/systemd
<DocScrutinizer05> the two annoying parts are: how is a chroot going to nuke host system's cgroups? if you can do this, cgroups are flawed anyway. And how is dang systemd supposed to recover from such issues without needed a reboot?
<MonkeyofDoom> I thought chroot was strictly filesystem, and cgroup separation requires a different namespacing call
Airwave has joined #neo900
paulk-leonov has joined #neo900
paulk-leonov has quit [Ping timeout: 240 seconds]
paulk-leonov has joined #neo900
cg132 has joined #neo900
<cg132> Looking for the Bankleitzahl (BLZ) for destination bank. Tis an 8 digit code but I cant find one that matches the SWIFT. Anyone know?
<DocScrutinizer51> 76070024
<cg132> Thanks Doc!
<cg132> You're the best.
<cg132> :D
<DocScrutinizer51> yw
cg132 has quit [Client Quit]
paulk-collins has joined #neo900
MonkeyofDoom has quit [Ping timeout: 250 seconds]
paulk-leonov has quit [Quit: Leaving]
paulk-collins has quit [Quit: Leaving]
SylvieLorxu has quit [Quit: ZNC - http://znc.in]
drrrz has quit [Ping timeout: 244 seconds]
tsuggs has joined #neo900