uvos has quit [Read error: Connection reset by peer]
TonyStone has quit [Remote host closed the connection]
amk has quit [Ping timeout: 260 seconds]
amk has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
Pali has quit [Ping timeout: 250 seconds]
TonyStone has joined #maemo-leste
inky has quit [Ping timeout: 256 seconds]
inky has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
mrkrisprolls has quit [Ping timeout: 250 seconds]
mrkrisprolls has joined #maemo-leste
xmn has quit [Remote host closed the connection]
<tmlind>
freemangordon: i don't have any current chromeos device, maybe the file is available for download somewhere though
<tmlind>
freemangordon: for tearing effect, looks like we may have some signaling misconfiguration in mainline, te triggers fine but only for some seconds to minutes with just your panel-dsi-cm changes
<tmlind>
then it hangs and we get the timeout errors and that's why the te got disabled earlier for the panel
<tmlind>
well te probably did not work at all earlier as it was missing some configuration looking at your patch
<tmlind>
after adding some trace_printk, looks like on framedone interrupt with te enabled the VC_TE counter is almost always 0 or very close to 0, so it seems like with te enabled, and the pending patch generating vsync on framedone, we should avoid tearing
<tmlind>
freemangordon: to me looks like the dsi related changes in your patch are not needed as omapdrm already configured te to set the VC_TE counter
<tmlind>
i guess i need to dump out the android dsi1 regs and diff the values to try to figure out if there's some signaling configuration issue
joerg has quit [Ping timeout: 240 seconds]
joerg has joined #maemo-leste
macros_ has quit [Ping timeout: 250 seconds]
macros__ has joined #maemo-leste
System_Error has quit [Ping timeout: 276 seconds]
mardy has joined #maemo-leste
<tmlind>
hmm looks even with current setup without te enabled, on framedone VC_TE is mostly empty, not sure what the signal in the te case for transfer complete is really supposed to be if there's no gpio line
<tmlind>
it seems that TE_TRIGGER_IRQ signals that the lcd module has started transferring after bus tunaround.. so maybe there's some bta interrupt after transfer complete after another bus turnaround?
Daanct12 has joined #maemo-leste
Danct12 has quit [Ping timeout: 250 seconds]
Daaanct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 250 seconds]
<tmlind>
oh there's also ACK_TRIGGER_IRQ with te enabled after framedone, that's probably what signals transfer completed from the panel
Daaanct12 has quit [Ping timeout: 256 seconds]
Danct12 has joined #maemo-leste
Daanct12 has joined #maemo-leste
Danct12 has quit [Ping timeout: 256 seconds]
Daanct12 has quit [Quit: Quitting]
Danct12 has joined #maemo-leste
System_Error has joined #maemo-leste
System_Error has quit [Ping timeout: 276 seconds]
System_Error has joined #maemo-leste
pere has quit [Ping timeout: 256 seconds]
elastic_dog has quit [Ping timeout: 245 seconds]
elastic_dog has joined #maemo-leste
pere has joined #maemo-leste
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #maemo-leste
Pali has joined #maemo-leste
System_Error has quit [Ping timeout: 276 seconds]
rafael2k has joined #maemo-leste
<rafael2k>
hi there, I'm rebasing the pp patches to latest 5.10.13, hope to finish in the weekend
<Wizzup>
rafael2k: hmm, we don't want 5.15?
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #maemo-leste
<rafael2k>
sorry
<rafael2k>
5.15.13
<Wizzup>
:)
<Wizzup>
did you figure out what we want built in?
rafael2k has quit [Ping timeout: 256 seconds]
rafael2k has joined #maemo-leste
<_inky>
rafael2k: yay
<rafael2k>
hi there!
<rafael2k>
Wizzup: no time yet
<rafael2k>
my keyboard was shipped
<rafael2k>
so my time is running over
<rafael2k>
:P
pere has quit [Ping timeout: 256 seconds]
rafael2k has quit [Ping timeout: 250 seconds]
pere has joined #maemo-leste
__20h___ is now known as __20h__
__20h__ has quit [Quit: WeeChat 3.0.1]
__20h__ has joined #maemo-leste
_inky has quit [Ping timeout: 256 seconds]
inky_ has joined #maemo-leste
inky has quit [Ping timeout: 250 seconds]
_inky has joined #maemo-leste
<Wizzup>
ok
<Wizzup>
uvos: I'll do the volume applet today :)
<jessicant>
is it possible to get the pinephone keyboard working with this yet?
xmn has joined #maemo-leste
fliessenkiller is now known as Schlitzestemmer
avoidr has quit [Quit: leaving]
avoidr has joined #maemo-leste
_inky has quit [Ping timeout: 256 seconds]
inky_ has quit [Ping timeout: 250 seconds]
inky_ has joined #maemo-leste
inky_ has quit [Ping timeout: 268 seconds]
inky_ has joined #maemo-leste
_inky has joined #maemo-leste
_inky has quit [Ping timeout: 250 seconds]
<Wizzup>
jessicant: I think it should
<Wizzup>
jessicant: we haven't been able to test it yet
<Wizzup>
jessicant: does it slide somehow, or is it just always attached?
<jessicant>
well it doesn't work out of the box
<jessicant>
it's always attached
<Wizzup>
jessicant: ah, you have one?
<jessicant>
yeah
<Wizzup>
jessicant: great, we have a new kernel and some other stuff to push out, it might work with that
<Wizzup>
I don't know what it required (a special driver?)
<Wizzup>
rafael2ks is active with the pine kernel now, and he also ordered the keyboard
<jessicant>
there's a userspace and a kernel space driver
<Wizzup>
right so we don't have the kernel one then I guess
<Wizzup>
I'll ask rafaek to pull these in
<Wizzup>
freemangordon: ping
<Wizzup>
freemangordon: I am seeing the display not turning on problems more frequently now (it happened again today), X is still running, anything I can do to provide a way to debug this?
<Wizzup>
freemangordon: it must be a recent change in kernel we did, or something the ddx, because I wasn't seeing this before I think
<Wizzup>
maybe it is somehow the fbdev emulation?
<Wizzup>
I think I see this every day now on the d4
<Wizzup>
it loks like X keeps retrying a thing in kernel drm that fails
<Wizzup>
this is a part of the trace (it's also in our logs):
<Wizzup>
17:40 < Wizzup> #0 0xb6a33f06 in ioctl () at ../sysdeps/unix/syscall-template.S:78
<Wizzup>
17:40 < Wizzup> #1 0xb6d24c76 in drmIoctl () at /usr/lib/arm-linux-gnueabihf/libdrm.so.2
<Wizzup>
17:40 < Wizzup> #2 0xb6d2923a in drmModeConnectorSetProperty () at /usr/lib/arm-linux-gnueabihf/libdrm.so.2
<Wizzup>
17:40 < Wizzup> #3 0xb66c3f12 in drmmode_output_dpms (output=<optimized out>, mode=0) at drmmode_display.c:797
<Wizzup>
in any case this is a very recent problem
<Wizzup>
and not that much has changed in the kernel, so I thought maybe it was this
<Wizzup>
I think I'm going to add the fbdev thing back in for now and see if it helps
<Wizzup>
uvos: btw you wrote: "Note that this plus the input device locking behavior of mce (even on fremantle) makes tklock (as opposed to vtklock) totally obsolete and redundant, it no longer serves any function."
<Wizzup>
uvos: how about showing notification counts, doesn't tklock do that?
<uvos>
your thinking about _vtklock)
<uvos>
tklock is the contraption that locks the device ts and keypad when its locked and the screen is off (also one click mode)
<uvos>
tklock was allways pretty mutch redundant, except the dbus interface for the volume keys and kinda one click mode, but really that was in mce too
<uvos>
mce just used to avoid applying one click mode itself when tklock was active
<Wizzup>
ah, I see
<Wizzup>
thanks for the explanation
<uvos>
oh btw on code i removed, i dident remove any functional code
<uvos>
so there are 2 things i "removed"
<uvos>
1 the volume slider used to check with pa about what the default stream was and set default_sink_name
<uvos>
and dident do anything at all with that
<uvos>
and 2 the slider dident set the volume immiately
<uvos>
instead 500ms where waited after the user last moved the slider
<uvos>
and then the volume was set
<uvos>
there is a bug in n900 hw that causes chaging the volume to result in auidble clicks
<uvos>
and this is was a hack around this
<uvos>
well noten entirley
<uvos>
there still is one click you can clearly hear in fremantle once it finaly sets the volume
<uvos>
but this hack tried to mitigate it
<uvos>
otherwise its just porting the interfaces
<Wizzup>
I thought the tick was part of the sound changing, like something that was played
<uvos>
nah its hw bug
<Wizzup>
right, but afaik there are ways for the applet to set the/track the volume on separate streams, because that did work somehow on the n900
<Wizzup>
hmmm I think I also hear it on the d4
<uvos>
yes this works
<Wizzup>
(will need to check later)
<uvos>
it tracks exactly 2 streams
<uvos>
in call and normal audio
<uvos>
this is unchainged
<uvos>
not really tracks, sets rather
<uvos>
honestly this is bad
<uvos>
(the whole applet)
<Wizzup>
so what I still don't understand is how it works the way it does in fremantle
<Wizzup>
where unplugging/plugging causes it to track the right speaker/hp sink
<Wizzup>
maybe it's one of the pulseaudio plugins or OHM
<uvos>
this is done below it
<uvos>
it just sets one proparty for media auido volume
<uvos>
its not a stream volume at all
<uvos>
its a stream proparty on the media streme
<uvos>
that something else needs to apply as volume
<Wizzup>
right, so that's probably ohm or pa
<uvos>
anyhow this is all pretty bad
<Wizzup>
the streams concept I am not sure is bad, but even so the media stream still differents in volume between hp/speaker
<uvos>
yeah but the streams apear to have been faked
<Wizzup>
this is also visible in how it renders the volume bar, it can be in completely different states
<uvos>
the volume applet makes it look liker there is only one stream
<Wizzup>
so it probably also fetches the current state somehow
<uvos>
and its role is changed
<uvos>
this is really a hack to how its supposed to work in pa
<uvos>
with different roles/profiles having own streams
<uvos>
Wizzup: no idea how meego audio works, ill read that again later. im just reporting on the volume slider
<uvos>
Wizzup: wich understands only one stream
<uvos>
besides call audio
mepy has quit [Ping timeout: 240 seconds]
<Wizzup>
check
<uvos>
oh and recveving events from xorg for the volume keys was also removed
<uvos>
since the ex-tklock dbus interface is sufficant
<uvos>
im not sure why they thought it nessecary to implement the input side of things twice
<uvos>
i think this is because the dbus interface also dident do key repeat, like mce, and they dident want key repeat moving the volume to full blast in the users pocket (android also behaves like this)
<uvos>
but i havent checked on fremantle if thats to
<uvos>
implementing the input frontend twich is an absurd way to provide this feature anyhow :P