chainsawbike has quit [Quit: yep... i broke it good that time...]
chainsawbike has joined #neo900
arcean has quit [Quit: Application terminated!]
Sysaxed has joined #neo900
<Sysaxed>
Hi! Why are there two accelerometers? One is LIS302DL and another one in BMX055
Pali has quit [Remote host closed the connection]
<bencoh>
Sysaxed: BMX055 isnt just an accelerometer
<bencoh>
dunno what we still need LIS302DL for though
<wpwrak>
for compatibility, in case some applications with a very long beard expect to be able to talk to it
<DocScrutinizer05>
for compatibility
<wpwrak>
faster ;-)
<DocScrutinizer05>
*yawn*
<Sysaxed>
bencoh: I know
<Sysaxed>
wpwrak: huh
<DocScrutinizer05>
and no, not applications in the strict def, but MCE which is part of maemo fremantle (closed) core middleware and controls all CSSU display orientation
<DocScrutinizer05>
and mute gesture
<DocScrutinizer05>
(screen down)
<bencoh>
DocScrutinizer05: compat with mce ?
<bencoh>
DocScrutinizer05: or other things that rely on sysfs ?
<bencoh>
cant we just have a dummy driver ? :p
<DocScrutinizer05>
no, since lis302 is way too complex to emulate the way it works in a dummy driver
<DocScrutinizer05>
and BMX055 is massively different in the way it works
<DocScrutinizer05>
I pondered that approach but thought it's not worth it. A chip for USD 2.- is the better solution
<DocScrutinizer05>
maybe also a tad of sentimental feelings since I started checking the way lis302dl works back in GTA02 times, and I developed concepts how drivers should work with this chip and evaluated all existing drivers in OM OS, in fremantle, and in upstream
<DocScrutinizer05>
I know the fremantle driver is almost perfect
<DocScrutinizer05>
((almost perfect)) lacks proper setup / export of the filter section. However the way MCE is *using* the chip is not exactly perfect
<DocScrutinizer05>
accelerometers are not simple sensors that provide 3 dimensions of g force
<bencoh>
thhey're not ? :)
<DocScrutinizer05>
and only upstread lis302 "driver" pretends they were
<DocScrutinizer05>
upstream
<bencoh>
well physically they're not, that's just a model
<DocScrutinizer05>
bencoh: no they're not. In embedded you must not do the luxury to poll them at 10Hz or whatever rate to detect any "event"
<DocScrutinizer05>
you need sophisticated triggering based on whatever complex machine to fire an IRQ when sth *interesting* happened
<DocScrutinizer05>
all *inside* the sensor
<DocScrutinizer05>
upstream driver devel had no F*ing clue about that
<DocScrutinizer05>
the fremantle and OM drivers are pretty good at putting lis302 complex IRQ "machine" to purpose
<DocScrutinizer05>
NB I don't think the BMX055 "machine" is inferior, prolly the opposite is correct. Just I don't know (yet) about the available drivers and their quality, and I'm absolutely sure the BMX055 machine cannot emulate the lis302 one
varu|zZz has quit [Ping timeout: 256 seconds]
mhanne_ has quit [Ping timeout: 256 seconds]
dos1 has quit [Ping timeout: 256 seconds]
gurki has quit [Ping timeout: 256 seconds]
jusa_ has quit [Ping timeout: 256 seconds]
misv has quit [Ping timeout: 256 seconds]
chainsawbike has quit [Ping timeout: 256 seconds]
wpwrak has quit [Ping timeout: 256 seconds]
bencoh has quit [Ping timeout: 256 seconds]
xes has quit [Ping timeout: 256 seconds]
DocScrutinizer05 has quit [*.net *.split]
DocScrutinizer51 has quit [*.net *.split]
kerio has quit [*.net *.split]
Axel_H has quit [*.net *.split]
afics has quit [*.net *.split]
thedead1440_ has quit [Ping timeout: 256 seconds]
mhanne has joined #neo900
gurki_ has joined #neo900
gypsy has joined #neo900
wpwrak_ has joined #neo900
bencoh_ has joined #neo900
bencoh_ has quit [Changing host]
bencoh_ has joined #neo900
chainsawbike_ has joined #neo900
bencoh_ is now known as bencoh
dos11 has joined #neo900
xes_ has joined #neo900
jusa__ has joined #neo900
chainsawbike_ is now known as chainsawbike
<bencoh>
bleh netsplit
dos11 is now known as dos1
thedead1440 has joined #neo900
misv_ has joined #neo900
DocScrutinizer05 has joined #neo900
<DocScrutinizer05>
kornbluth dead, sorry
<DocScrutinizer05>
err split
DocScrutinizer05 is now known as 77CAAI591
DocScrutinizer05 has joined #neo900
DocScrutinizer51 has joined #neo900
kerio has joined #neo900
Axel_H has joined #neo900
afics has joined #neo900
77CAAI591 has joined #neo900
77CAAI591 has quit [Changing host]
DocScrutinizer05 has quit [Disconnected by services]
77CAAI591 is now known as DocScrutinizer05
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #neo900
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #neo900
DocScrutinizer05 has quit [Client Quit]
DocScrutinizer05 has joined #neo900
xes_ has quit [Quit: Going offline...]
wpwrak_ is now known as wpwrak
jusa__ is now known as jusa_
nox- has quit [Quit: Leaving]
<DocScrutinizer05>
wpwrak: wb!
<wpwrak>
the intertubes are bumpy today :)
<DocScrutinizer05>
usual weekend freenode wars
<DocScrutinizer05>
an ultrashort netsplit
<DocScrutinizer05>
allegedly "down: sinisalo(v6)" -- according to my own observations it been kornbluth though which split off from the rest
norly has quit [Quit: Leaving.]
<DocScrutinizer05>
((accel drivers)) my concept how a decent driver should work is roughly (and simplified): a framework (middleware) arbitrates between all requests from apps who want to know about accel/orientation events, selects the most "demanding" requirements and sets the accel sensor in a way so it triggers an IRQ only when a change happens that's sufficiently large enough so it could meet the event conditions of one of the apps' requests. In case
<DocScrutinizer05>
of lis302 that's the highpass filter in lis302 which creates an IRQ when a sufficiently steep change in raw sensor readings happens. Additionally middleware could set some absolute thresholds that trigger when e.g. screen facing more towards down that towards up. Additionally middleware could do a readout of absolute (raw) sensor data every e.g. 60 min to handle ultraslow changes in orientation
<DocScrutinizer05>
depending on capabilities of sensor you might also want to allow for events that trigger on "timespan without any change above a certain level", iow "n seconds of 'silence'"
<DocScrutinizer05>
useful for e.g. detecting end of a walk
<DocScrutinizer05>
I don't know of a sensor allowing such "duration of silence event", so either the driver or the middleware has to implement it, in the most power economic way
<DocScrutinizer05>
e.g. >>mask IRQ so CPU won't ware up, but enable IRQ latching on sensor when acceleratipon above a certain threshold occurs. After n seconds driver checks if sensor IRQ mask has a pending IRQ which means the last n seconds were no 'silence' <<
<DocScrutinizer05>
s/ware/wake/
<DocScrutinizer05>
note how tha latter concept differs from what 99.99% of sw-devels would implement. They would do the timing in software on CPU, reacting on every little change event on accel and then deciding in software if the threshold they defined been tripped by the event - or even polling the accel at a constant sample rate and do the same threshold detection for N readings per second
<DocScrutinizer05>
and actually that's exactly the only operation mode upstream lis302 driver supports
<DocScrutinizer05>
at least last time I checked
<wpwrak>
depends on what you expect your power situation to be. if you're running off mains, then sure, poll whenever and then do it in sw. else, you want to reduce the wakeup event rate. e.g., in linux, timers can be done this way.
<wpwrak>
and "nothing happened for time X" can just be done by using regular timers. no support in the sensor needed. (besides, it's usually orders of magnitude more efficient to use timers)
<DocScrutinizer05>
no, in embedded power saving is rule #1, and that's invariably achieved by 100% IRQ driven design
<wpwrak>
yup. so your 99.99% of sw devels are web designers or such ;-)
<DocScrutinizer05>
why wake up CPU to reset a timer when the sensor can aggregate all events during a timespan while a timer on CPU expires and CPU sleeps?
<wpwrak>
no, i mean: if "nothing happened" is an event, then it's best handled by a timer mechanism close to the CPU. i.e., don't do this in the sensor.
<DocScrutinizer05>
you should try powertop resp zzztop on N900 ;-)
<wpwrak>
nice name :)
<DocScrutinizer05>
yes, you use a timer for n seconds of CPU sleep, then cpu wakes up and checks if sensor detected some event during the idle time
<wpwrak>
yes, you can do that if you have "data collection" events. i.e., things that don't need immediate action but that still have to be done. e.g., things like sampling a small counter before it wraps.
<DocScrutinizer05>
btw maemo times are "funny" resp smart, in that they allow a certain intentional 'jitter' so multiple timer expiration times can get merged when they are close enough to each other
<DocScrutinizer05>
so CPU only has to wake up once to service multiple timer events
<DocScrutinizer05>
timers*
<wpwrak>
that's a nice idea
<DocScrutinizer05>
aiui when you have one periodic timer with period 100ms that gets started at h:m:s.020s and one timer that fires every ful second (think clock), the periodic 100ms timer will get shifted to be in sync with the full second one
<DocScrutinizer05>
or maybe they delay the full second timer by 0.020s to fire at h:m:s:020 too,
<DocScrutinizer05>
I guss quite some nifty algos could get implemented into this mechanism
<DocScrutinizer05>
there's areason why maemo has exceptionally good standby times despite using full multitasking and no suspend as e.g. OpenMoko OS does
<DocScrutinizer05>
of course app devels can spoil the whole thing easily by ignoring the design rules
<DocScrutinizer05>
when a developer of a alarm clock / stop watch app thinks his app needs a display refresh rate of 50/s, there's hardly anything the OS can do about it since the OS doesn't know that it's an incorrect approach for a stop watch and not a movie player that _needs_ this frames/s rate to sho decent animation
<DocScrutinizer05>
other OS went the restrictive approach, even to the extent of suspending apps that are in background
<DocScrutinizer05>
maemo assumes competent devels
<DocScrutinizer05>
and a working QA in maemo-testing
<DocScrutinizer05>
and provides a core system that has all the tools in toolbox to actually do decent apps
<DocScrutinizer05>
e.g. there's a reason maemo comes with alarmd instead of cron
<DocScrutinizer05>
and there's also a reason for some "proprietary" kernel drivers that do _not_ do silly braindead polling like upstream lis302 driver does
<DocScrutinizer05>
you'd be surprised how many even "kernel devels" actually are sort of web "programmers"
<DocScrutinizer05>
"web designers"
<DocScrutinizer05>
not to mention e.g. qt-sensors or whatever been the name, qtmobility or sth
<DocScrutinizer05>
sensorfw
<DocScrutinizer05>
"software controls sensor" seems the only paradigm they ever heard of. The event driven architecture where actually the sensor controls the software sounded like nonsense to them, at least when I tried to discuss it with them
<DocScrutinizer05>
"sensor: a character device you can poll at arbitrary rates"
<DocScrutinizer05>
eventually they adopted relative char devices (like mouse) where a read() only returns when new data available. Which is sort of a step in right direction, but worthless unless you also provide means to precisely instruct sensor *when* to deliver "new data"
<DocScrutinizer05>
they should think of $arbitrary_sensor being rather identical to cmos clock alarm
<DocScrutinizer05>
_first_ you define all the conditions that make for an event, _then_ you wait for the event to happen
<DocScrutinizer05>
on event you read out current data to determine which were the conditions that actually triggered the event
<DocScrutinizer05>
and you immediately set up next event conditions
<DocScrutinizer05>
then act on the current event and go to sleep again after you're finished with that
<DocScrutinizer05>
this procedure description already gives clear indication that you need either a middleware to arbitrate between concurrent requests to same sensor, or you need very smart "multiplexing" drivers that have a set of per-process individual device nodes so no process even notes that another process concurrently acesses same (sensor)device. Much like with audio
<DocScrutinizer05>
maemo already has such a concept, alas only for liblocation
<DocScrutinizer05>
dpkg-reconfigure for sure is no default package on target maemo platforms
<stryngs>
Ah
<stryngs>
so it should be missing then
<stryngs>
removing fakedebconf and installing debconf is ok, yes?
<stryngs>
I'm building a native package builder for the n900 DocScrutinizer05 =)
<DocScrutinizer05>
sorry, no idea about such stuff. I just know you're not supposed to build on target, we got scratchbox SDK for that
<stryngs>
I know
<stryngs>
But im a stubborn SoB =)
<stryngs>
And so, i build natively
<stryngs>
Now I want to make it proper, versus my local build technique
<stryngs>
So i'm porting all the SB stuff to the n900, in the process i evidently saw an ertror i had never seen before, a warning for dpkg-reconfigure
<stryngs>
figure MAYBE it
<stryngs>
is because i killed fakedebconf
<stryngs>
rebuilt fakedebconf and it doesnt have it, so i think im good, but want to ensure =)
<DocScrutinizer05>
I suggested a few times to check that setting in maemo's 'contacts'(SMS) app's menu
wicket64 has joined #neo900
<wpwrak>
that's of course the very first thing i did :) everything is perfect as far as normal user-visible settings are concerned
<DocScrutinizer05>
you also tried the "use SMS central number of SIM" option?
<DocScrutinizer05>
I don't know what's your definition of "perfect" in that regard
<DocScrutinizer05>
the perfect setup would be the one that works ;-)
<DocScrutinizer05>
until then there are only a number of options, none of which I'd consider more perfect than the others
<DocScrutinizer05>
either use SIM-defined SMSC-number, or use user-defined SMSC-number, and there you got quite a few alternatives both for the number itself as well as the format you use (leading '+', leading '00', leading countrycode without any prefix like +/00, and number without countrycode and network code)