<wpwrak>
freemangordon: yup, i like modern kernels :)
<Joerg-Neo900>
I like Pali's powerkernel
<wpwrak>
Joerg-Neo900: cheers ! :)
<Joerg-Neo900>
really the ONLY compatibility issue I know of is with that SSL(?) lib shit
<wpwrak>
SSL ?? how is that even possible ? :)
<Joerg-Neo900>
which is quite unfortunately linked against some closed source apps
<wpwrak>
oh, i see
<wpwrak>
so it's an API issue ?
<Joerg-Neo900>
yes
<Pali>
what? with ssl?
<Joerg-Neo900>
ssh? TLS?
<Joerg-Neo900>
no not ssh
<Joerg-Neo900>
I'm pretty sure ssl 0.98 or something, while recent incompatible API version is like 1.x
<Joerg-Neo900>
I didn't follow too closely since... well, SSL
<Pali>
but whats with it?
<wpwrak>
and you can't just install the ancient version, for compatibility ? of course, then you'd also get some very nice security issues that have been fixed long ago everywhere else ...
<Joerg-Neo900>
>>I asked H. J. Lu why ldconfig doesn't automatically set up the linker names. His explanation was basically that you might want to run code using the latest version of a library, but might instead want development to link against an old (possibly incompatible) library. Therefore, ldconfig makes no assumptions about what you want programs to link to, so installers must specifically modify symbolic links to update what the linker will use for a
<Joerg-Neo900>
library.<<
<Joerg-Neo900>
sure we can't fix the old closed source apps that link against libssl.0.9.8, but we can install libssl.1 (*different* .so name!) and still keep the legacy libssl.0 around and keep the old apps running
<freemangordon>
:nod:
<freemangordon>
and I guess redhat will support 0.9.8 for some more years
<wpwrak>
MonkeyofDoom: it's a bit like ipv4 vs. ipv6. it's a bad idea to rely on ipv4, but it'll work. and it's been like that for MANY years :)
<MonkeyofDoom>
there are situations where you can't use IPv6 for lack of hardware or ISP support
<MonkeyofDoom>
there's no such problem keeping people from using GTK3
<wpwrak>
gtk2 has the benefit that the deployed api is stable. with gtk3, you can run into compatibility issues, i.e., by using functions that don't exist in the deployed versions. so you have to keep track of what distros are doing. with gtk2 you don't have that problem.
<wpwrak>
not that i'd be advocating to not use gtk3 because of that, but it is a nasty little issue that can come up
<MonkeyofDoom>
there's no usable web rendering engine built on the GTK2 stack
<MonkeyofDoom>
and it ties you to X11
<MonkeyofDoom>
there are a lot of downsides; it might be the only thing that's feasible to ship due to legacy software that depends on it, but it isn't in any way a forward-looking choice
<wpwrak>
well, i think they're planning to move to gtk 4 soon, so that'll effectively freeze the api
<wpwrak>
and yes, gtk3 is nice. i have code with gtk2 (fped) and gtk3 (eeshow), and i like the latter better. just the compatibility issues are annoying.
<MonkeyofDoom>
yeah
<MonkeyofDoom>
GTK3 isn't perfect, but it at least has active development
<MonkeyofDoom>
and most things are improved vs. GTK2
<wpwrak>
and sometimes a surprising lack of documentation or examples. e.g., i tried to copy & paste (just text, to the clipboard) in a multi-head environment, and it acts very weird. not quite sure if that's a bug in gtk3 or if i just missed the right magic incantation. i ended up launching xsel, which works fine :)
<MonkeyofDoom>
the clipboard is weird and complicated on X11 in general
<MonkeyofDoom>
but the GTK API for it certainly doesn't help
<wpwrak>
(very weird) i.e., i copy on screen :0.1 then try to paste on :0.2. strangely, nothing happens. but when i close the application, then suddenly the paste occurs. so it seems some event doesn't get processed. but i haven't found any clue about that, also looking at the very few other programs i found with google, that use that api. puzzling.
<wpwrak>
and yes, i looked as the xsel source. scary :)
mzki has quit [Ping timeout: 260 seconds]
cc___ has quit [Ping timeout: 246 seconds]
knttl has quit [Ping timeout: 256 seconds]
knttl has joined #neo900
qws-user-1228 has quit [Read error: No route to host]
Pali has quit [Ping timeout: 258 seconds]
qws-user-1228 has joined #neo900
jonwil has quit [Quit: ChatZilla 0.9.93 [SeaMonkey 2.40/20160120202951]]
herpderphurr has joined #neo900
arossdotme has quit [Quit: Ex-Chat]
arossdotme has joined #neo900
arossdotme has quit [Remote host closed the connection]
arossdotme has joined #neo900
goiken- has quit [Ping timeout: 245 seconds]
goiken_ has joined #neo900
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #neo900
neo900 has joined #neo900
Joerg-Neo900 is now known as Guest62682
neo900 is now known as Joerg-Neo900
Guest62682 has quit [Killed (rajaniemi.freenode.net (Nickname regained by services))]
herpderphurr has quit [Quit: Leaving]
qws-user-1229 has joined #neo900
qws-user-1228 has quit [Read error: Connection reset by peer]
jonwil has joined #neo900
<freemangordon>
Joerg-Neo900: what is "keysight DMM"?
<freemangordon>
ah,google answered
<freemangordon>
no, I have some cheapo chinese one
<varu>
^ mine was acquired gratis :D
<varu>
you have to power most of the cheap ones with a 9v battery.. who knew!
xman has quit [Ping timeout: 260 seconds]
<brolin_empey>
I guess that DMM in this context means Digital Multi-Meter.
<varu>
yes
wiewo has quit [Ping timeout: 256 seconds]
wiewo has joined #neo900
freemangordon has quit [Ping timeout: 244 seconds]
mzki has joined #neo900
paulk-collins has joined #neo900
freemangordon has joined #neo900
Pali has joined #neo900
cc___ has joined #neo900
louisdk has joined #neo900
jonsger has joined #neo900
chainsawbike has quit [Ping timeout: 256 seconds]
SylvieLorxu has joined #neo900
chainsawbike has joined #neo900
jonwil has quit [Quit: ChatZilla 0.9.93 [SeaMonkey 2.40/20160120202951]]
<Pali>
DocScrutinizer05: do you know what is final state, if n900 supports ECI headets in HW or not?
Satyricon has quit [Remote host closed the connection]
trx has quit [Ping timeout: 260 seconds]
<Joerg-Neo900>
Pali: hw does support for all I can tell
<Joerg-Neo900>
what's missing is the driver putting the hw gear to work
<Pali>
Joerg-Neo900: there is driver only for TWL5031
freemangordon has quit [Remote host closed the connection]
<Joerg-Neo900>
anyway obviously SIH[6|7] struct is only defined for TWL5031, not *030
<Pali>
yes, looks like it is not available for twl4030
<Joerg-Neo900>
in N900 we have a input/rcv signal ECI_AD on twl ADCIN2 (probably could also be used as output for sending, though it has a 1k series resistor to MIC(BIAS) ) and a two hardware-implemented voltage threshold sensors generating IRQ via OMAP GPIO (pin U3, H1) useful for holdbutton-push and similarly for low latency receive-timestamping. And we have a GPIO (ECIbus:5, OMAP GPIO_182) that can control the voltage on MIC via switching N4022 analog
<Joerg-Neo900>
switch 2SEL, for sending serial data by pulling MICBIAS to low voltage. The supposed ECI frequency/baudrate is in the range of 10ms to 0.01ms per bit, with a tendency clearly to the lower
<Pali>
178 /* there are no SIH modules #6 or #7 ... */
<Joerg-Neo900>
TWL5031 does all that serial in-out shuffling obviously/supposedly via an UART
<Joerg-Neo900>
that's what 6, 7 are for
<Joerg-Neo900>
I never seen them function blocks described in any TRM
<Joerg-Neo900>
no surprise (both "Nokia has non-pub..." and "I've never seen these function blocks described") since ECI is (C) Nokia
<Pali>
The Jack itself is similar, I mean the connector pinout. But in N900 there is no HW for ECI. In N95 and N9 there is.
<Pali>
"Unfortunately I do not know about the N900 public documentation."
<Joerg-Neo900>
yes, that's his "simplified" view of things. N900 has no TWL* support for ECI
<Joerg-Neo900>
so in N900 the CPU needs to bitbang the serial, while in N9 it can have the TWL5031 UART doing that instead
<Joerg-Neo900>
for transmitting data the task is pretty straight forward, using a kernel driver that exploits a hw timer to toggle a GPIO in a strict schedule, at up to maybe 20kHz. No biggie for a OMAP at 600MHz, not even at 250MHz
<Joerg-Neo900>
for receiving you need a IRQ handler that just does a timestamp and pushed that onto a stack for a worker thread to analyze the serial data
<Joerg-Neo900>
btw for sending data maybe have a look at LIRC driver for N900, aiui it also does bitbang to create the IT-LED carrier frequency (up to 56kHz iirc) and the on-off modulation
<Joerg-Neo900>
s/IT-/IR-/
<Joerg-Neo900>
for receiving you might find a nice template in openmoko freerunner drivers for smart battery (bq27000) HDQ single wire
<Joerg-Neo900>
there must be a kernel IRQ handler (FIQ ? not sure about that) that takes a timestamp for each edge detected on the HDQ pin, and a worker thread analyzing the timestamps and converting them to data bytes
freemangordon1 is now known as freemangordon
<Joerg-Neo900>
wpwrak: do you have any details in your mind about freerunner HDQ battery interface still? ^^^
<wpwrak>
Joerg-Neo900: i think andy used an FIQ for this, yes. but that's about as much as i remember.
<Joerg-Neo900>
Pali: and *absolutely worst case* we could simply sample the inbound data as *audio signal* and then analyze it ;-)
<wpwrak>
do it like the big boys: constantly stream it to cloud.neo900.org, have it analyzed there :)
<Joerg-Neo900>
HRRHRRRHRR
<Pali>
I was thinking about that analyze of audio signal... but on laptop (to supports connected ECI headset on laptop)
<Pali>
no idea if integrated audio cards on laptops are too crapy to filter needed eci audio signal...
<Joerg-Neo900>
that might work, but the main problem on laptop is *sending*, since you need "ultrafast" on/off of MICBIAS
<Joerg-Neo900>
the generic micbias control is waaay too slow for that
<Joerg-Neo900>
probably
<Joerg-Neo900>
it likely has large buffer caps since it's a power supply (for the mic)
<Pali>
should micbias for it be always on (on laptop)?
<Joerg-Neo900>
dunno
<Pali>
iirc we have it on n900 always on, when headset is connected
<Joerg-Neo900>
I guess usually you have no micbias on laptop, they assume dynamic (unpowered) microphone
<Pali>
in cssu
<Pali>
to support headset button
<Joerg-Neo900>
yep, should. for enabling holdbutton music control
<Pali>
yea, that prolog code which is running on n900
<Joerg-Neo900>
yep
<Joerg-Neo900>
that obscure shite
<Joerg-Neo900>
also blob :-((
<Joerg-Neo900>
and of course completely undocumented
<enyc>
ooh lots eing discussed =)
<Joerg-Neo900>
yeah
<Joerg-Neo900>
if it wasn't for that obscure audio control crap, the whole maemo audio porting to new platforms would be a magnitude simpler
<Joerg-Neo900>
meh, where was this reasoning that Nokia gave? like "audio is too important on a phone to allow users messing with it" - OHMY
<Joerg-Neo900>
((analyze of audio signal... but on laptop)) the nasty part: aiui any ECI headset won't talk as long as it doesn't receive initialization data from host (laptop)
<Joerg-Neo900>
I gonna try borrow a N97 plis ECI headset from my friend matokla and give it a good shot with the scope
<Joerg-Neo900>
plus*
* enyc
more generally wondering what hardware problems coming into being
<enyc>
i remember heling out with repackaging tools needed for project etc
<Joerg-Neo900>
hm?
<Joerg-Neo900>
repackaging tools? is that "tools for repackaging" or "toold got repackaged"? and for hardware? I can't relate that to any topic I know of
<Joerg-Neo900>
we switched form eagle to kicad. That's accomplished now
louisdk has joined #neo900
arossdotme has quit [Ping timeout: 240 seconds]
xman has joined #neo900
louisdk has quit [Ping timeout: 260 seconds]
pigeons has joined #neo900
xman has quit [Ping timeout: 252 seconds]
<enyc>
Joerg-Neo900: yes it may wel have been kicad... fun with packaging, source, chroots, virtualizers iirc
<Joerg-Neo900>
that was kicad :-)
<enyc>
ooh i see new schematics
<Joerg-Neo900>
yeah, and the greatest schematics we ever had :-)
<Joerg-Neo900>
not like they couln't get better still, by a tad of consolidating and cleaning
<enyc>
and different eyes looking at them for 3vil_bugs
<enyc>
I'm hoping once that proto is working, some sort of realistic "path-to-completion" can then be published, which may help with further investors/orders imho but there you go ...
<Pali>
woooow... 18 hours took until gcc finished linking libQtWebKit.so.4.7.4 binary
<Pali>
I cannot believe that GNU ld linker spawned by g++ is such slow...
<Joerg-Neo900>
swap hell?
<Pali>
no
<Pali>
ld is slow
<Pali>
it was in scratchbox
<Pali>
where is old gcc (for maemo) and it has quadratic or cubic algorithm for traversing symbols and dependencies
<Pali>
and libQtWebKit contains also some javascript lib (static linked)
<Pali>
too many symbols
<Pali>
and I'm using scratchbox in qemu with just 200MB of RAM
<Pali>
GNU ld for such huge libs with couple of symbols (also private, not exported, internal debug) needs more than 4GB ram for effecienty
<atk>
qtwebkit is also old and full of bugs
<Pali>
new GNU ld/gold has linear algorithm for this
<atk>
there's qtwebengine now but it's still OOP sadly.
<Pali>
but maemo scratchbox has old
jonsger has quit [Ping timeout: 265 seconds]
<Pali>
btw, llvm cannot be compiled on 32bit machine with gcc-4.8 and GNU gold ld
<Pali>
it needs to mmap more then 4GB address space, which is not possible on 32bit mode
<atk>
hah
<Joerg-Neo900>
((I'm using scratchbox in qemu with just 200MB of RAM)) toldya, swap hell :-D
<atk>
Some of my machines only have 4GiB of RAM
<Pali>
Joerg-Neo900: I was checking disk usage, and no it was not used
<Pali>
that ld process used internal cpu at 100%
<Joerg-Neo900>
modified swap hell, instead of reading in symbols into RAM and then swapping out RAM to disk, it just traverses disk every time for every symbol (simplified picture)
<Pali>
yes
<Pali>
but that was in my physical RAM
<Joerg-Neo900>
oooh
<Pali>
kernel probably loaded those qemu disk pages to RAM
<Joerg-Neo900>
well, the dis structures (aka sourcecode) are not exactly b-tree optimized ;-)
<Pali>
as I really did not see physical disk activity
<Pali>
new GNU gold linker has linear algorithm, now I see what quadratic and linear means for QtWebKit!
<Joerg-Neo900>
so despite virtual disk in physical RAM, it had to parse sourcecode over and over again, instead of looking up symbols in an optimized b-tree or whatever hash table
<Pali>
yes, something like that
<Joerg-Neo900>
you better had provided all that RAM used by virtual disk to the qemu virtual RAM
<Pali>
next time when I will need to compile qt I do that
<Pali>
until now I never needed more RAM for compiling maemo apps
<Pali>
for 6 years!
<Joerg-Neo900>
I've seen a roughly similar effect when yast/zypper/yum built the dependency tree for distro packages for update or install of a new package. it also took 20h on my CF-27 with 200MB RAM
<atk>
my experience with yum has shown that it would be faster to manually keep dependencies and package file ownership information in a notepad than it would be to run yum to do an update
<Joerg-Neo900>
hehe
<Joerg-Neo900>
luckily yum is dead
<Joerg-Neo900>
err wait
<Joerg-Neo900>
prolly still used in redhat etc
<atk>
centos
<Joerg-Neo900>
aahyes that too
<Joerg-Neo900>
no idea bout RH
<Joerg-Neo900>
Suse uses zypper now
<Joerg-Neo900>
works
<Joerg-Neo900>
well, I also have no laptop with a feeble 200MB RAM anymore ;-P
<atk>
my first laptop had 256MiB of ram.
<atk>
Sadly the screen on it failed eventually but I think the machine itself still works
<atk>
It's just that in the process of trying to work out what happened to the screen I might have misplaced all the screws so I never put it back together again.
<atk>
Might try to see if I can find a repair manual for it (I have one for my thinkpad) which lists the screws I need and their locations.
<atk>
I could get it up and running as some server