<uvos>
and DFBARGS="system=fbdev,no-cursor,linux-input-grab"
<uvos>
or charging_sdl
<uvos>
sdltest should show different colored squares
<uvos>
as soon as usb power is remvoed the squares stop
<uvos>
reapplicaton resumes them immidatly
<parazyd>
heh
<parazyd>
Is this perhaps something controlled by the kernel?
<uvos>
idk it seams really wierd
<uvos>
thats why tmlind ^^^ maybe he knows
<parazyd>
Do you get the same on bionic btw?
<uvos>
no idea its not charged atm
<parazyd>
ok
<parazyd>
Mine neither
<uvos>
also would be knida hard to test
<tmlind>
uvos: oh interesting, sounds like some regulator or vbus voltage automatically switches the lcd to video mode from command mode, otherwise manual refresh ioctl is needed. sre might have some better ideas
<uvos>
tmlind: you know the manual refresh ioctl?
<uvos>
the name
<tmlind>
uvos: also plugging in hdmi causes that, might be the 5v line triggering it either vbus or hdmi 5v
<uvos>
tmlind: ok
<tmlind>
uvos: don't remember what the ioctls was, but i added that to the kexecboot sources so it should be there, sorry busy right now
<uvos>
rn thats default where the alarm will then display correctly.
<Entitlement>
parazyd - [ maemo.org - Talk - View Single Post - Maemo5 boot process ]
<parazyd>
If you set an alarm on your Fremantle N900 and power it off, then you'll see what happens
<uvos>
yeah i know what it dose
<uvos>
but it can go in all of the deamons dsme mce etc
<parazyd>
As I said, if possible, it'd be best to have it as a runlevel
<parazyd>
And probably as Wizzup says, built on top of charge-mode, e.g. switching to an alarm fire runlevel
<uvos>
that is all well and good
<uvos>
but rn there is a huge amount of code that uses the old mode swiching machinery that is not required for anything and i was suggesting a milestone to remove it
<uvos>
this machenery is what the code internaly calls act-dead
<parazyd>
I think it's best if you can make a ticket
<parazyd>
And list these programs/locations
xmn has joined #maemo-leste
<sicelo>
:-)
* sicelo
goes into act-dead mode
<uvos>
btw someone should look at ke-recv
<uvos>
it mostly dosent work right on mainline
<uvos>
its also a bit redundant with mce in large parts.
<uvos>
we should fix what isent redundant and deduplicate what is somehow
xmn has quit [Quit: Konversation terminated!]
xmn has joined #maemo-leste
<Wizzup>
uvos: what doesn't work in it (I guess I know some of it doesn't work well)
<Wizzup>
I think I did the initial udev port
<uvos>
the memory management interface it uses plain dosent exist and the camera stuff is a very n900 sepcific hack,
<uvos>
keyboard slide monitoring works fine but mce dose that too and is device configurabel so we should do this only once
<uvos>
the usb stuff looks sane enough
<uvos>
idk about all the little tools that share the repo
<uvos>
some of these seam rather unfortionat
<uvos>
stuff like mmc-format.c reimplementing mkfs.vfat
<uvos>
seams silly
<Pali>
fyi, you should update dosfstools (mkfs.fat, fsck.fat, fatlabel) to latest version
<Pali>
maemo fremantle used mlabel from mtools project due to bugs in fatlabel in dosfstools project
<Pali>
but now last version of dosfstools should have fixed all these issues
ollieparanoid[m] has quit [Ping timeout: 276 seconds]
venji10[m] has quit [Ping timeout: 276 seconds]
venji10[m] has joined #maemo-leste
kek has quit [Ping timeout: 240 seconds]
kek has joined #maemo-leste
ollieparanoid[m] has joined #maemo-leste
ravelo has quit [Quit: Connection closed for inactivity]
ravelo has joined #maemo-leste
Oksana has quit [Ping timeout: 240 seconds]
<sicelo>
why did we have a fork of iio-proxy btw?
<uvos>
sicelo: i forked it because then current version was systemd only, while current git is init system agnostic
<sicelo>
I'm noticing something that seems weird - iio proxy in pmOS reads total opposite rotation, with the same matrix applied via udev
<uvos>
so i had to change the debain packaging
<sicelo>
What about the version in devuan?
<uvos>
sicelo same kernel
<uvos>
there is (maybe was) no version in devuan
jonsger has quit [Remote host closed the connection]
<sicelo>
Okay.
<sicelo>
On pmos I have 5.125.12-rc2 kernel
<uvos>
slow down future man :P
<sicelo>
*5.12-rc2
<uvos>
okay
<uvos>
and you are using the same kernel driver
<uvos>
and kernel rotation matrix in dts?
<sicelo>
Yes
<uvos>
if exists
<sicelo>
No, I think rotation matrix isnt in dts
<uvos>
ok
<sicelo>
I copied the udev rule
<uvos>
then if udev is the same idk how that could happen
<sicelo>
I'm clueless myself, tbh
<uvos>
is the rule applying?
<uvos>
check uvdev info
<sicelo>
Yes, udevadm info -e shows rule applies
<uvos>
hmm
<uvos>
ok no clue
<sicelo>
Nice that on N900 I didn't need to make rotation matrix :p
<uvos>
the other devices follow google oritentation rules
<uvos>
z is toward screen and y is up i think
<uvos>
n900 is wierd
<sicelo>
N900 iio driver is exactly the same as what d4 uses , lol
<uvos>
yeah but the physical orentation of the cip
<uvos>
chip
<uvos>
there is a spec for that
<uvos>
its "wrong" on n900
<sicelo>
So what's weird? If it comes up correct without needing a rotation matrix, sounds like someone did the right thing
<uvos>
well iio-sensor-proxy is made for laptops
<uvos>
the spec dosent apply there
<uvos>
oh well its pretty insignificant
<uvos>
:P
<sicelo>
Lol, you always have to find fault with N900. Did you even use it with the driver I'm talking about?
<uvos>
no
<uvos>
but the driver should be irrelivant
<uvos>
it should not swap physical axis
<sicelo>
Anyway, pmos people recommend we should be adding rotation matrices to dts. Is that something we would consider?
<uvos>
yes
<uvos>
and the mapphones have them
<uvos>
but they are again to spec
<uvos>
and so for portrait
<sicelo>
So why did you make the udev rule then?
<uvos>
because we want landscape to be normal
<uvos>
so we have to break it on devices that have natural porait orientation
<uvos>
i dont think introducing that quirk to the kernel is a good idea
<uvos>
so in leste-config/udev is stays
sunshavi has quit [Remote host closed the connection]
<sicelo>
So the matrix in kernel might be wrong :-/
<uvos>
hmm what device?
<sicelo>
Droid 4
<uvos>
no its correct iirc
<uvos>
per spec
<uvos>
spec say something like z is towards screen from back y is up and x is right when compeard to natural device orientation
<uvos>
(or something to that effect)
<uvos>
we (leste) want "up" to be on the long side of the display
<sicelo>
Okay just checked. Definitely wrong
<uvos>
ok
<uvos>
well we should fix it then
<sicelo>
Please test
<uvos>
could you open a issue?
<sicelo>
Looks like it should be 1,0,0,0,1,0,0,0,-1
<uvos>
ok
<uvos>
hmm no that cant be
<uvos>
no way the chip outputs a non cardian coordinate system
<uvos>
maybe the driver has a bug
<sicelo>
Or the values I'm getting are biased by the wrong one in kernel
<sicelo>
The driver does have bugs actually ... those bugs are the reason why N900 accelerometer hasn't been working with iio
<sicelo>
Let me switch back to pmOS
<uvos>
ok btw what i wrote above was wrong
<uvos>
z is towards screen from back y is up and x is RIGHT
<uvos>
based on natural device orientation
<sicelo>
Yes, a lot of what you're saying is wrong :D
<uvos>
?
<Wizzup>
let's stay civil now
<uvos>
ofc the spec dosent say x is left
<uvos>
that again would be non cartesian
<uvos>
or left handed or whatever
<sicelo>
It stands to reason that what's correct is what we actually observe.
<sicelo>
So with the udev rule deleted, iio proxy reads normal when keyboard is upside down
<sicelo>
And right-up when the device is in portrait
<uvos>
thats wrong if iio-sensor-proxy is to spec
<uvos>
check sysfs
<uvos>
y should be negative in portrait
<uvos>
and xz should be about 0
<sicelo>
That's what I'm saying ... the matrix in dts seems to be wrong according to these tests
<uvos>
yes x an y are fliped
<uvos>
looks like maybe the matrix should just be removed
<uvos>
or set to identiy
<sicelo>
Thanks for checking
<uvos>
your welcome
<sicelo>
I wonder how this will be fixed ... if we change dts, we potentially break this for other users
<uvos>
sicelo: ah no
<uvos>
sicelo: its fine
<sicelo>
what's fine?
<uvos>
the matrix is correct
<uvos>
its just not appling for some reason
<uvos>
so its 0 -1 0 | 1 0 0 | 0 0 1
<uvos>
and in portrait x is postive and yz are 0
sunshavi has joined #maemo-leste
<uvos>
if you run that though the matrix
<uvos>
you get nagative y and xz zero
<uvos>
as per spec
<uvos>
so its not being picked up
* sicelo
also boots n900 ... I bet it's in spec :-p
<uvos>
quite possible
<sicelo>
Why wouldn't it be picked up ... the dts looks ok
<uvos>
while seting up the matrixes for leste
<uvos>
i was quite certin the maphones were correct
<uvos>
and then the n900 was different so i thought it was out of spec
<uvos>
sicelo: idk
<uvos>
ill check it out later
<uvos>
im out of time rn
<sicelo>
Where's the spec btw
<uvos>
kernel source ABI/testing/sysfs-bus-iio
<uvos>
* Y is in the plane of the screen and is positive towards the
<uvos>
top of the screen ;
<uvos>
* X is in the plane of the screen, perpendicular to Y axis, and
<uvos>
positive towards the right hand side of the screen ;
<uvos>
* Z is perpendicular to the screen plane and positive out of the
<uvos>
screen.
<uvos>
An implementor might consider that for a hand-held device, a
<uvos>
'natural' orientation would be 'front facing camera at the top'.
<uvos>
The main hardware reference frame could then be described as :
<uvos>
this is mostly copyed from googels spec for android
<uvos>
anyhow ttyl
<uvos>
sysfs is fine
<uvos>
just somehow the matrix gets lost on the way to iio-s-p
<cockroach>
hmn, I'm trying to build an image but I keep getting "[E] error in: bootstrap_complete_base". how do I find the actual error message?
uvos has quit [Ping timeout: 252 seconds]
cr4y1_ has quit [Ping timeout: 240 seconds]
<sicelo>
uvos, I have figured it out.
<sicelo>
1. There spec doesn't care how the sensor is mounted. So there's no 'ansolutely' right and wrong way. That's precisely why there's provision for a mount matrix
<sicelo>
2. Even though the mapphones have a correct, or wrong matrix defined in dts, it doesn't get used, because the driver doesn't support that :-)
<sicelo>
You can see the absence of mount-matrix property in the device tree binding for this sensor/driver
<sicelo>
So that's why the mount matrix in dts never gets picked up by iio-sensor-proxy
<sicelo>
So either someone updates the driver to understand dts, or, we're stuck to udev way (which does work fine)