<Wizzup>
we also should make the pinephone pro work
<uvos__>
the images contain Packages found in chimaera:
<Wizzup>
someone made it work and then left I think
<uvos__>
devel has Packages found in chimaera-devel:
<uvos__>
Wizzup: maybe promote the kernel soon? i thought you did already
<uvos__>
are there any outstanding issues im not aware of?
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
<Wizzup>
uvos__: let's do it
<Wizzup>
I have been working 16 hour days sinxe oct 10 or so
<Wizzup>
including weekends, so I had no time/energy
<Wizzup>
but it's getting better now
<uvos__>
Wizzup: great!
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
<xmn>
That is tough Wizzup. Hopefully it continues to ease up back to normal.
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
kiva has quit [Quit: Client closed]
hm has quit [Remote host closed the connection]
hm has joined #maemo-leste
vectis_ has quit [Read error: Connection reset by peer]
vectis_ has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
Wizzup: btw if you promote 6.6 and build new imgs, hope gconf2 and dbus errors we got in last stable imgs (when upgrading to devel) disappear.
<Wizzup>
I think those errors appeared only once, no?
<arno11>
not sure what happened
<arno11>
last time i tried a recent img it was really buggy
<arno11>
but i don't remember exactly
<arno11>
it happens to sicelo as well iirc
<arno11>
and to some guys from tmo
<arno11>
*i mean, the gconf and dbus error
<dsc_>
arno11: did you try this pidgin-chatgpt
<arno11>
not yet, will try soon
<arno11>
and let you know
<arno11>
dsc_: the plugin itself works fine :) so it should be trivial to make it working in conversations
<dsc_>
so ehh
<arno11>
however, it works only for 4-5 requests then reset the chat apparently
<dsc_>
idk anything about the pidgin stuff
<arno11>
the plugin is a purple plugin
<dsc_>
doesnt it not then automatically work via purple, yeah
<arno11>
so it should work in converstions using mctool
<dsc_>
ah ok
<dsc_>
so it only needs the gtk dialog for API key
<arno11>
yup
<arno11>
i'll try to add it through mctool (but i maybe need a reboot)
<arno11>
hmm i don't know which manager it uses
<dsc_>
no idea
ceene has quit [Ping timeout: 246 seconds]
<arno11>
anyway the plugin seems to have limited capacity in term of context saving (giving a kind of memory to chatgpt)
<arno11>
after 4 or 5 requests, it only remembers the first one
pere has quit [Ping timeout: 265 seconds]
<arno11>
i don't encounter this problem in bash since i found a way to add as many contexts as i need
<dsc_>
arno11: this project seems to be 1 week old
<dsc_>
so maybe still in development
<arno11>
yes indeed
fab_ has quit [Ping timeout: 252 seconds]
fab_ has joined #maemo-leste
fab_ has quit [Ping timeout: 255 seconds]
arno11 has left #maemo-leste [#maemo-leste]
System_Error has quit [Remote host closed the connection]
fab_ has joined #maemo-leste
fab_ has quit [Read error: Connection reset by peer]
fab_ has joined #maemo-leste
fab_ has quit [Remote host closed the connection]
Livio has joined #maemo-leste
uvos__ has quit [Ping timeout: 276 seconds]
<freemangordon>
Wizzup: I think I fixed osso-abook in regards to attribute names/ vcard field, however, it seems sphone abook plugin does a mess in rtcomel DB
<Wizzup>
hmm
<freemangordon>
will push to -devel later on
fab_ has joined #maemo-leste
Livio has quit [Ping timeout: 260 seconds]
pere has joined #maemo-leste
uvos__ has joined #maemo-leste
<inky>
> currently as far as i am aware we lack a maintainer for the pinephone kernel
<inky>
> the omap devices are all on 6.6 already
<inky>
>
<inky>
i built 6.11 on pinephone/gentoo so i can try to do the same for maemo.
<inky>
i guess hildon is easier to maintain, it stands alone, all or most of the services are started by xsession scripts.
akossh has joined #maemo-leste
System_Error has joined #maemo-leste
mrkrisprolls has quit [Ping timeout: 276 seconds]
akossh has quit [Ping timeout: 245 seconds]
akossh has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
sicelo: btw something to improve @als/mce is the minimum level of backlight: a way too high on n900 (50% iirc). not ideal in the dark. 5-10% is enough imo. i personaly use 2%
<arno11>
and it is not ideal for power draw
<arno11>
and not progressive enough
uvos has joined #maemo-leste
<uvos>
arno11: you can configue the brighness levels vs lux values however you want in mce.ini
<uvos>
however the default is way lower than 50%
<arno11>
ok for mce.ini but the minimum is really around 50%
<sicelo>
someone just shared (on telegram) a video of Leste running on xiaomi prime 4 with the pmOS kernel. it's SW rendered for now, but I guess they'll get GPU playing along soon
<uvos>
arno11: no its 20
<sicelo>
what % are those BTW?
<uvos>
yes
<uvos>
note that mce never lowers the brigtness while the display is on
<uvos>
it only raises it
<uvos>
unless you set NoAlsLowering to 0
<arno11>
so i'm pretty sure something keeps minimum value too high. let me check again
<sicelo>
Anyway, my als aim was to extract the correct calibration from cal on the n900, which should hopefully result in more accurate lux readings
<uvos>
sicelo: ok
<uvos>
rn mce dose scale the als valuse
<uvos>
but really this isent mces job
<uvos>
sysfs has a scale file that udev reads, if you cant set the scale file correctly in dts you should set the udev proparty
<uvos>
iio-s-p then scales the sensor based on that
<arno11>
uvos: i just doublecheck and default minimum real value is 51
<sicelo>
iio-s-p doesn't really do justice to n900's als - it reports two separate channels, but iio-s-p, as a generalization application, tried to represent a
<sicelo>
all in one way
<uvos>
i cant parse that sentance
<sicelo>
mine or arno11 's?
<uvos>
yours
<uvos>
arno11: cover the sensor, check monitor-sensor to see that it reports 0 lux
<uvos>
click on the the lowest profile in the display settings app
<uvos>
turn off the display
<uvos>
turn on the display
<arno11>
ok
<sicelo>
iio-s-p expects one sysfs node for the als. n900's als reports two - they work differently. hence you'll see in older mce code that there was calib0 and calib1 properties, for example
<uvos>
sicelo: ok what makes them different?
<uvos>
sicelo: different angles?
<sicelo>
the one is simply sensitive to normal light, and the other to light & ir
<arno11>
uvos: it always report 0
<uvos>
arno11: then its broken
<sicelo>
Anyway, I don't have time to work on it for the time being, but I think I can do something about it in future
<uvos>
this will indeed cause mce to use 50
<uvos>
sicelo: anyhow if something needs to be fixed about it needs to be fixed in iio-s-p, mce is a consumer of the als data with no external sensor interfaces, so any other application needs the values to be correct too
<uvos>
i gues a iio-s-p maybe should read a composit of both values or something
<uvos>
sicelo: i presume your als works fine?
<uvos>
ie arno11 has hw failure?
<sicelo>
arno11, the als is working ... I'm guessing it's night there too, so yes lux reading will mostly be 0
<arno11>
ok
<arno11>
let me try next to a light
<arno11>
yes indeed it works
<uvos>
ok anyhow
<uvos>
if you do the above you should get 20%
<uvos>
if you dont i gues something is broken on your device
<uvos>
or n900 genrally
<uvos>
since it works fine on d4
<arno11>
default minimum value is still 51
<uvos>
what do you mean by "default"
<uvos>
the lowest brightness profile ie 1 bar
<uvos>
is the one that should have 20% at zero lux
<arno11>
with one bar it is 51%
<uvos>
when the display is turned on at 0 lux that is
<uvos>
where are you reading that from?
<arno11>
there is a huge diff if i set it @20% by hand
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
<arno11>
uvos: from /sys/class/backlight/acx565akm/brightness
<uvos>
ok
<arno11>
*20% by hand @0 lux
<uvos>
?? if you set it by hand obv the lux wont matter
<arno11>
so something seems wrong on leste n900 in general, fremantle backlight is fine on my device
<arno11>
uvos: yes indeed
<uvos>
anyhow i gues it could be broken somehow, maybe sicleo can confirm it
<arno11>
yes maybe
<uvos>
i think mce prints what it sets the brigtness too
<uvos>
if you run it with -v -v
<uvos>
ie stop mce
<uvos>
and then start it as root (sudo su -)
<uvos>
with mce -v -v
<uvos>
and see what it prints when you switch brigness profiles
<uvos>
and change the lux
Anasko has quit [Remote host closed the connection]
<arno11>
ok
Anasko has joined #maemo-leste
<uvos>
turning off no als lowering will help with debuging
<uvos>
since the brigness will then directly follow lux
<sicelo>
arno11: on fremantle it's using the full capabilities of the als. iio-s-p somewhat averages the separate results into one, so yeah, the behavior will not be comparable. plus fremantle uses proper calibration values (I assume, measure somehow from factory ' haven't yet tested if the calibration values are similar across devices, although I doubt)
<uvos>
sicelo: dosnet matter
<uvos>
if he sees 0 lux it should choose the lowest level
Livio has joined #maemo-leste
<uvos>
the sensor reading is not the issue here
<uvos>
sicelo: droid4 android has its callibration values fixed in dts
<sicelo>
I'm not necessarily answering the particular % stuff (I don't even know where the % being referred to are found) :-D
<uvos>
i dont think theres mutch variation really
<uvos>
oh wait
<uvos>
arno11: its fine
Anasko has quit [Remote host closed the connection]
<uvos>
your reading /sys/class/backlight/acx565akm/brightness
<uvos>
thats wrong
Anasko has joined #maemo-leste
<uvos>
/sys/class/backlight/acx565akm/brightness is not in %
<uvos>
its some arbitary value
<uvos>
how you scale the value to get % is given by the other sysfs files
<uvos>
(brigtness_steps or so iirc)
<sicelo>
20/255
<uvos>
on d4 its out of 16
<uvos>
anyhow 51/255 = 0.2
<uvos>
so its working exactly as intended
<uvos>
if thats to bright for you just change the values in mce.ini
<uvos>
those ARE in %
<arno11>
ok
<arno11>
but yeah a way to high for me :P
<uvos>
if there is some consensus that its way to high we can change it in n900's specific mce.ini
<uvos>
mce.ini.d/SOMETHING-n900.ini
<uvos>
otherwise this is working as intenden
<uvos>
d
<arno11>
ok
<uvos>
if 20 in /sys/class/backlight/acx565akm/brightness you should set the lowest brightness in your 99-user.ini to 8
<uvos>
*if 20 is what you like
Anasko has quit [Remote host closed the connection]
<arno11>
ok thx
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
alphazone has quit [Ping timeout: 260 seconds]
akossh has quit [Ping timeout: 260 seconds]
alphazone has joined #maemo-leste
akossh has joined #maemo-leste
gnarface has quit [Quit: Leaving]
alphazone_ has joined #maemo-leste
<sicelo>
arno11: BTW with fremantle you use kernel-power or the vanilla Nokia kernel?
gnarface has joined #maemo-leste
alphazone has quit [Ping timeout: 260 seconds]
<arno11>
sicelo: i use kernel power 53
<arno11>
working fine @1GHz :P
<sicelo>
:-)
<arno11>
btw opera mini still works fine on it, wonder if it could not be the solution for leste
<arno11>
at least a usable solution
<arno11>
for n900 ofc
<arno11>
but it needs phoneME to work well
<arno11>
not foss iirc
<sicelo>
mmm. it isn't?
<sicelo>
there's some j2me thing that should presumably work on modern linux. Will see if I still have its url. never tried it though
<arno11>
we can use microemulator but it is a way slower than phoneME
<arno11>
iirc opera mini works with microemulator but it is not user-friendly an slow on n900
<arno11>
with phoneME on fremantle, even google streetview works fine
<arno11>
*btw
<arno11>
ah, i remember now: phoneME is still on gh but difficult to compile (at least for me)
<sicelo>
looks like sphone should use the services of hildon-plugins-notify-sv perhaps? or profiled ...
fab_ has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
<uvos>
sicelo: no
<uvos>
this is simply unimplemented
<uvos>
we have no "rining" volume
<uvos>
the setting in profiled goes no where
<uvos>
the correct sollution is to have ucm role for this (and alarm)
<uvos>
on fremantle there is a special sink that is used for this
<uvos>
again essentally the same thing as a ucm profile achived though different means
fab_ has quit [Quit: fab_]
Anasko has quit [Remote host closed the connection]
<uvos>
but yeah this has nothing to do with sphone per say
Anasko has joined #maemo-leste
<sicelo>
sure, doesn't matter to me how exactly it's implemented (i think the one in profile goes through nsv from a quick check) ... anyway, the problem is real and *some* solution would be appreciated
Anasko has quit [Remote host closed the connection]
<uvos>
nsv reads it
<uvos>
but its pointless
Anasko has joined #maemo-leste
<uvos>
as it just outputs though the regular hifi sink
<sicelo>
looks to me Like it actually does set a volume
<uvos>
yes, but as metioned this is pointless
ceene has joined #maemo-leste
<sicelo>
no idea what you mean. anyway, my point is - as things stand currently, it's easy to miss calls Unintentionally. i don't particularly care about profile or nsv per se, but just saying reducing media playback volume should not also reduce ringing volume.
<uvos>
sure
<uvos>
thats not question
<uvos>
but the audio setup is not to the point where this is possible
<uvos>
we need to do more pa work for it to happen
uvos has quit [Remote host closed the connection]
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
<inky>
sicelo, how do you feel daily using it?
<inky>
i do it but without phone calls, and with pidgin and email.
<sicelo>
it's fine. it's not the first time i daily it ... just I need a battery. only gripe i have is non-working USSD.
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
akossh has quit [Quit: Leaving.]
mrkrisprolls has joined #maemo-leste
inky has quit [Quit: Gateway shutdown]
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]