<freemangordon>
however, they don't on d4 and I suspect PA issue
<freemangordon>
ut don;t really know how to debug
<freemangordon>
*but
apac has joined #maemo-leste
Livio has quit [Ping timeout: 264 seconds]
<Wizzup>
freemangordon: how do they not work on d4, this is vm to d4 and d4 doesn't work? or no audio?
Livio has joined #maemo-leste
pere has quit [Ping timeout: 276 seconds]
Livio has quit [Ping timeout: 264 seconds]
leste has joined #maemo-leste
_fab has quit [Read error: Connection reset by peer]
_fab_ has joined #maemo-leste
Anasko has quit [Ping timeout: 252 seconds]
f_ is now known as f_|AWAY
f_|AWAY is now known as f_
pere has joined #maemo-leste
ungeskriptet has quit [Ping timeout: 248 seconds]
apac has quit [Quit: Konversation terminated!]
ungeskriptet has joined #maemo-leste
coffeecreature has left #maemo-leste [So long!]
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #maemo-leste
kiva has joined #maemo-leste
coffeecreature has joined #maemo-leste
<kiva>
Interesting they don't have any problem with N900 main on front camera: https://elinux.org/N900
<kiva>
does them work with Leste?
<kiva>
I mean main and front camera.
coffeecreature has left #maemo-leste [So long!]
<freemangordon>
Wizzup: this is N900 <-> d4, audio most of the times does not work (and PA volume control does not show vcm streams)
<inky>
wow n900 camera has support in mainline? does it work? with which software?
<Wizzup>
kiva: inky: elinux.org is old and it's not up to date
<Wizzup>
freemangordon: I've seen PA crashes on the d4
<Wizzup>
this might be what you're seeing
<Wizzup>
maybe see if PA gets killed or something
<freemangordon>
hmm, ok
<Wizzup>
let me find the error
<sicelo>
i do keep elinux.org up to date :-)
ceene has quit [Read error: No route to host]
<sicelo>
kiva: inky: no one has played with it much. after all, that camera was quite bad even with Fremantle. but you can modify the dts and give it a go
<Wizzup>
user.log.4.gz:2025-04-30T13:17:39.403881+02:00 localhost pulseaudio[13475]: [alsa-sink-40124000.mcbsp-cpcap-hifi cpcap-hifi-0] alsa-mixer.c: Assertion 'm' failed at ../src/modules/alsa/alsa-mixer.c:1479, function pa_alsa_path_select(). Aborting.
<Wizzup>
freemangordon: I see this regularly ^
<Wizzup>
sicelo: okay, great, ty
ceene has joined #maemo-leste
<Wizzup>
freemangordon: I tried to search pi source a bit but didn't get very far yet
<Wizzup>
s/pi/pa/
coffeecreature has joined #maemo-leste
arno11 has joined #maemo-leste
<dsc_>
setting up pinephone with leste today
kiva has quit [Ping timeout: 240 seconds]
Daanct12 has quit [Quit: WeeChat 4.6.3]
<dsc_>
how can I force orientation to portrait (for pinephone) - is there a command?
<dsc_>
it does not seem to adjust itself (the gyro is possibly disabled, idk)
<dsc_>
also; why is landscape 'slower' than portrait ?
<Wizzup>
you need to upgrade for the sensor proxy to work
<Wizzup>
landscape is slower because the opengl rotation fallback is software not gpu
narodnik has quit [Quit: WeeChat 4.6.3]
<dsc_>
Wizzup: alright, why is opengl rotation software? :P
<dsc_>
maybe you have a link somewhere in hildon?
narodnik2 has quit [Ping timeout: 276 seconds]
<Wizzup>
dsc_: that's in glamor (the 3d driver) not hildon
<Wizzup>
it's in mesa
arno11 has quit [Quit: Leaving]
kiva has joined #maemo-leste
kiva has quit [Client Quit]
kiva has joined #maemo-leste
<kiva>
sicelo: To me would be enough if can take picture and send it with MMS at 640x480 resolution with Leste. Actually N900 camera lens is not bad, but sensor need somekind of whitebalance correction matrix, should calibrate with greycard, but that is only needed if you want 5MP pocket camera quality.
<kiva>
also QR-code or barcode reader would be nice use for N900 camera.
<kiva>
dsc: Pinephone has hardware accelerated rotate and zoom and 2 layers, but if I understand right it is feature of AllWinner, not Mali GPU part itself...I wonder is there enough documentation of that feature to make open source driver? Was there any closed source driver for any kernel version?
xinomilo has quit [Ping timeout: 252 seconds]
<inky>
> how can I force orientation to portrait (for pinephone) - is there a command?
<inky>
it does (well it did for me in chimaera), i think on daedalus too.
<inky>
otherwise there is /usr/share/hildon-desktop/transisions.ini where you can whitelist apps that are allowed to be rotated.
<dsc_>
I upgraded leste and orientation started working :)
<dsc_>
but thanks
<dsc_>
and yeah, its slow
<inky>
and there is kernel boot flag fbcon=rotate:1
<inky>
that's for landspace actually.
<sicelo>
kiva: front camera? ever tried it with Fremantle? it really wasn't that good, even for the low resolution
<gnarface>
kiva: there was a BSP kernel v4.9 that supposedly supported "everything" but i'm not sure where to get it
<gnarface>
...4.9? 3.9? something old anyway
<gnarface>
i thought it was linked from their wiki at some point but i'm having trouble finding it now
<kiva>
sicelo: I took raw pictures with Fremantle ten years ago was that Bless900 that better camera app?
<sicelo>
you mean rear camera then
<kiva>
sicelo: yes...front camera is just 640x480 and real quality is even lower.
<kiva>
front camera pictures looked like 320x240 or even lower.
<sicelo>
i think that's what arno has talked about a number of times?
<dsc_>
likely. I think this may also be present on droid4
<dsc_>
because the scrolling is also not super smooth there
<dsc_>
not slow by any means, but not smooth
<dsc_>
I assumed this was because of the droid4, but know I'm thinking maybe there is something wrong with the acceleration
<dsc_>
now*
vectis_ has joined #maemo-leste
kiva has joined #maemo-leste
kiva has quit [Ping timeout: 240 seconds]
kiva has joined #maemo-leste
apac has joined #maemo-leste
<Wizzup>
it depends on the driver
<kiva>
Pinephone users without keyboard might want arrow-up and enter into downbar of osso-xterm.
kiva has quit [Quit: Client closed]
arno11 has joined #maemo-leste
<arno11>
dsc_: something wrong with acceleration, yes, but not conversations specific: rather Qt5 is at fault
<dsc_>
with software rendering I get 130fps, with opengl 26fps
narodnik has joined #maemo-leste
<dsc_>
for a simple Qt5 widgets + QML scene
<dsc_>
i will look with renderdoc
<arno11>
indeed...there is a problem lol
<arno11>
dsc_: btw on n900, using QT_QUICK_BACKEND=software is quite as slow as using hardware
<arno11>
*slow, specially to launch an app
<arno11>
btw 26 fps seems similar to n900
<arno11>
*with opengl
<dsc_>
arno11: how do you test?
<dsc_>
to see this fps
<arno11>
running hildon desktop with fps shown
<dsc_>
how do you show FPS?
<arno11>
don't remember the command, let me check
Livio has joined #maemo-leste
<dsc_>
nvm, I can find it
<arno11>
i still wonder what is qt5ct raster magic: 5-6 times faster to launch one or 10 qt apps. and no performance diff
<arno11>
anyway...
ceene has quit [Ping timeout: 248 seconds]
pere has quit [Ping timeout: 244 seconds]
Livio has quit [Ping timeout: 264 seconds]
Livio has joined #maemo-leste
narodnik2 has joined #maemo-leste
Twig has quit [Remote host closed the connection]
pere has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
_fab_ has quit [Quit: _fab_]
<dsc_>
how to calibrate battery on pinephone
apac has quit [Quit: Konversation terminated!]
Anasko has joined #maemo-leste
kiva has joined #maemo-leste
Livio has quit [Ping timeout: 264 seconds]
<kiva>
dsc: I calibrated battery running it empty and then full charing..there is problem that it try start up when you connect charger, but try shut down as fast you can.
<dsc_>
kiva: it says calibration needed
<dsc_>
this solves itself via your steps?
<kiva>
yes
<dsc_>
thx
<dsc_>
and display brightness, you know how to adjust that?
<kiva>
go Settings, there is Display and there is brightness, it has little slow response and difference is small..maybe that can be fixed.
<sicelo>
not 100% sure how MR-ready that actually is, but it makes a lot of sense to me
<dsc_>
ill play around with it
<sicelo>
should work for sure. but i'm just not happy that it will treat energy_now == 0 && percentage == 0 as being un-calibrated, even when those values are correct :-p
<sicelo>
but this whole battery stuff does involve a lot of compromise anyway
<dsc_>
"The interval given is in terms of monotonic time, not wall clock time. See g_get_monotonic_time()."
<dsc_>
??
<dsc_>
thx glib
<sicelo>
mce supports hardware fading only on the N900
<kiva14>
actually that fading time is not problem, because if steps for Pinephone would be 1, 800, 1600, 2400 and 3124 then change is more visible.
<sicelo>
scratch that ... this is not LED :-)
* sicelo
should been long asleep anyway
<dsc_>
yeah, it just writes to /sys/class/backlight/backlight/brightness
<dsc_>
but it does so too slow
<Wizzup>
yeah the steps seem to be the problem no?
<dsc_>
yes
<kiva14>
no if write to sys/class/ 3124 and then 1 it change instantly.
<dsc_>
I have step_time "1" now, its faster, but I want to understand what it is :D
<dsc_>
its the interval to g_timeout_add
<dsc_>
but I dont think its milliseconds
<dsc_>
anyway
<sicelo>
another solution would be to define the steps in an mce key, since, after all, there may be devices where the linearity (or visibility) of the change cannot be expressed in an easy formula (e.g. 20%, as we seem to have it)
<dsc_>
yeah
<sicelo>
timeout_add is ms
<kiva14>
if ask me Pinephone does not have linear brigness value.
<dsc_>
ok ye
<sicelo>
linear wasn't the correct word actually, but my English fails me :-)
<kiva14>
:)
<dsc_>
with step_time=1, from step 1 (brightness 624) it executed that callback 1251 times, and 624+(1251*2) = 3126
<Wizzup>
sicelo: too bad mainline doesn't offer another more simple interface
<dsc_>
ahh ok, so the step length should be dynamic/related to the overall size
<dsc_>
then we'll fix it, regardless of step_time
<dsc_>
because I dont like firing a function every 1ms
<Wizzup>
it's non-linear
<dsc_>
but like sicelo said, maybe better to hardcode some stuff
<kiva14>
But anyway we (who we?) should only change step1 value from 624 to 1...get full brightness control. Value one is enough bright.
<dsc_>
yeah but going from 624 to 3126 is not linear, im just talking about fixing the duration bug
<dsc_>
i mean
<dsc_>
ok this is becoming chaotic
<dsc_>
but what I mean is, going from 624 to 3126 is linear
<Wizzup>
has anyone tried using brightnessctl?
<Wizzup>
brightnessctl s 40% (or whatever) seems to do the right thing
<sicelo>
on maemo? no. i use it on my laptop
<Wizzup>
it's available in daedalus
<Wizzup>
could we just call it for 20/40/60/80/100% ? :D
<dsc_>
easy fix is making step length take into account the overall size of the total length
<sicelo>
i am not fully sure yet what's the problem with what we already have btw, haha. we calculate the values wrong? or the issue is the fading?
<kiva14>
but 1/40/60/80/100 would be better.
<Wizzup>
dsc_: that doesn't work with non-linear doesn't it?
<dsc_>
Wizzup: there is a callback (function call) which increments a number to a target value, the bigger the number, the longer it takes to get there (because the increments are static (2))
<sicelo>
kiva14: it's not so simple. some devices may have a very big difference in brightness for that 40% :-)
<dsc_>
I can make it call the function more often (decrease step_time) but this is a hack
<Wizzup>
ok yeah whatever the smooth thing is should just never run for more than a second
<sicelo>
e.g. Droid 4 max_brightness is 7 :-)
<dsc_>
so the easy fix is to make the increments related to how big the change is
<Wizzup>
to me the bigger problem seems mce not supporting non-linear backlights
<kiva14>
sicelo: conditional compile for Pinephone? Or 1/25/50/75/100? or more steps?
<kiva14>
If ask me more steps.
<sicelo>
kiva14: that's why i think easiest/safest 'cheat' is a key in mce. it can be per device (leste-config-<device>).
<dsc_>
do you have a droid, i'd like to see max_brightness there
<sicelo>
it's 7 :-)
<dsc_>
I'm guessing its not a high number
<dsc_>
right, thats why it goes fast there xD
<kiva14>
sicelo: it would be good. And more steps ;)
<sicelo>
i totally agree that the increment shouldn't be static ... it should be derived from the whole range
<sicelo>
that way if the range is large, some values are skipped
<dsc_>
right
<dsc_>
ill change it
<kiva14>
So if add one step to UI then Droid would have all values (I assume that 0 is off), one step more would be good also for Pinephone 1/20/40/60/80/100
<kiva14>
that was in persent, not real values.
kiva14 has quit [Quit: Client closed]
<dsc_>
if the increments are 2, and max brightness is 7 on droid, was it ever fully 100% :P