Pali has quit [Ping timeout: 250 seconds]
humpelstilzchen[ has quit [Ping timeout: 248 seconds]
jedertheythem[m] has quit [Ping timeout: 268 seconds]
n00mann[m] has quit [Ping timeout: 250 seconds]
humpelstilzchen[ has joined #maemo-leste
Livio_ has quit [Ping timeout: 252 seconds]
jedertheythem[m] has joined #maemo-leste
n00mann[m] has joined #maemo-leste
joerg has quit [Ping timeout: 244 seconds]
joerg has joined #maemo-leste
macros_ has quit [Ping timeout: 260 seconds]
macros_ has joined #maemo-leste
xmn has quit [Remote host closed the connection]
akossh has joined #maemo-leste
xmn has joined #maemo-leste
mardy has joined #maemo-leste
akossh has quit [Quit: Leaving.]
norayr has left #maemo-leste [Error from remote client]
norayr has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
rafael2k has joined #maemo-leste
<freemangordon> ok, vkb works in empathy :)
alex1216 has joined #maemo-leste
rafael2k_ has joined #maemo-leste
<freemangordon> a little buggy still, but well...
rafael2k has quit [Ping timeout: 268 seconds]
<Wizzup> freemangordon: :)
dev has left #maemo-leste [Disconnected: closed]
dev has joined #maemo-leste
uvos__ has joined #maemo-leste
pere has quit [Ping timeout: 265 seconds]
<freemangordon> Wizzup: does not work in either FF or chromium
<freemangordon> I wonder why
pere has joined #maemo-leste
<uvos__> freemangordon: ff and chromium are not really any toolkit
<uvos__> they use the webengine to render everything inc the ui
<freemangordon> yes, but thay should have some integration with input methids
<uvos__> ff uses gtk to integrate with linux
<uvos__> but this is skin deep often
<uvos__> sure
<uvos__> there is also the option of useing atispi
<uvos__> i have some code that works with this
<uvos__> also the x11 option will allways be needed
<uvos__> since there are applications with random or no tooklits
<freemangordon> sure
<freemangordon> hmm, why it stopped working?
<uvos__> what stopped working/
<uvos__> ?
<freemangordon> vkb in empathy
<uvos__> it did?
<freemangordon> yes
<uvos__> what toolkit dose that sue?
<freemangordon> gtk3
<uvos__> so the x11 backend dosent work?
<freemangordon> I ported im module to gtk3
<uvos__> oh ok
<uvos__> no idea i never used any of this
<freemangordon> well, I just use empathy as test tool
<freemangordon> for gtk3 application
<freemangordon> oh, it seems h-i-m crashed :D
alex1216 has quit [Ping timeout: 268 seconds]
rafael2k_ is now known as rafael2k
<uvos__> wrt replacement
<uvos__> for him
xmn has quit [Ping timeout: 265 seconds]
<uvos__> examining how phosh and the plamo keyboards work might be usefull
<uvos__> iirc plamo is derived from the meego keyboard
<freemangordon> then it is tied to qt
<uvos__> well him is tied to gtk2
<freemangordon> no, I mean that it works only in qt
<uvos__> and has other defficancies too
<Wizzup> him works in x11 too, no?
<Wizzup> :)
<uvos__> not sure how that is different to him really
<freemangordon> we will have to write plugins for gtk
<uvos__> not sure how that is different to him really
<uvos__> xD
<freemangordon> we already have plugins for gtk :P
<uvos__> 2
<uvos__> but not qt
<uvos__> so its neigher here nore there
<freemangordon> we have code for qt4
<uvos__> also plamo may have done so allready
<uvos__> at least for gtk3
<freemangordon> yeah
<freemangordon> backport to gtk2 shoudl be trivial
<freemangordon> uvos__: ok, but what is the situation with browsers?
xmn has joined #maemo-leste
<freemangordon> as for toolkits is more or less the same
mardy has quit [Ping timeout: 265 seconds]
mardy has joined #maemo-leste
<uvos__> where?
alex1216 has joined #maemo-leste
<freemangordon> hmm, my ubuntu has vkb that is able to type cyrillic if FF
<freemangordon> *in FF
<Wizzup> wouldn't at spi help with browser input?
<Wizzup> imho the main him shortcoming is no arrow keys / support for that mode (direct input) and portrait being a bit cramped
<Wizzup> otherwise it's not bad
<uvos__> freemangordon: onboard
<freemangordon> yes
<uvos__> yes onboard works on qt and gtk
<freemangordon> Wizzup: adding arrows is easy
<uvos__> directt input however
<uvos__> goes against the way him works fundamentaly
<freemangordon> not really
<freemangordon> see special symbols vkb for example
<uvos__> well the vkbs are on a plugin interface
<uvos__> that expects strings
<uvos__> sure there are special exceptions also for enter etc
<uvos__> but really in the main
<uvos__> it expects to transfer finished strings
<freemangordon> we can always add one more atom for direct input
<uvos__> imo this requires rearchitecting the plugin interface to the extent that you might as well replace him
<Wizzup> burn down and rewrite is not my fav way of doing things, but we can do it in some cases
<Wizzup> for maemo leste we're rarely doing the burn down approach
<Wizzup> :)
<uvos__> replace dosent nessecarly mean rewrite
<uvos__> since we could try and use something that exitst
<uvos__> the main obstical here is
<uvos__> hildon-desktop
<uvos__> hidon-desktop dosent support the atom usualy used by the vkbs to dock themselves to the bottom of the display
<uvos__> and dosent support multi window at all
<uvos__> but this is also the same problem with him
<uvos__> if you add direct input
<uvos__> and if you solve this defficancy in h-d
<uvos__> then onboard would for instance simply work
<uvos__> (but maybe be not ideal on a phone screen)
<uvos__> then you can see if the phosh keyboard would not simply work too
<freemangordon> ok, seems chromium somhow obeys gtk3 IM, as when that new plugin is added, hwkb typing is ignored
<uvos__> (imo it should)
<freemangordon> so, it is a matter of fixing it and it should work
<Wizzup> I have a hard time imagining it on landscape
<Wizzup> freemangordon: nice
brabo has quit [Remote host closed the connection]
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
dev has left #maemo-leste [#maemo-leste]
dev has joined #maemo-leste
_uvos_ has joined #maemo-leste
uvos__ has quit [Ping timeout: 260 seconds]
<_uvos_> something ate my commens
<_uvos_> btw at-spi
<_uvos_> id like to mention again that with at-spi you could in the main make the x11 backend behave like the gtk2 one
<freemangordon> hmm, focus_in etc is called
<_uvos_> ie field click opens vkb etec
<freemangordon> so it is really some bug
<_uvos_> and that works in _every_ toolkit
<freemangordon> great
<freemangordon> I have no experience with that though
<_uvos_> there is some proof of concept code
<_uvos_> in the him repos as a branch
<_uvos_> freemangordon: its pretty undocumented
<_uvos_> at-spi is also a huge security risk
<Wizzup> (and all DEs use it(
<Wizzup> )
<_uvos_> that in wayland allows you to read a lot of stull that makes "X11 insecure"
<_uvos_> here is proof of concept code
Pali has joined #maemo-leste
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
<freemangordon> ok, our chromium is buggy in regards to gtk IM
<freemangordon> hmm, actually upstream is buggy too
<freemangordon> it never calls gtk_im_context_set_client_window() unless a key is pressed
Livio_ has joined #maemo-leste
Livio_ has quit [Changing host]
Livio_ has joined #maemo-leste
Livio has quit [Ping timeout: 268 seconds]
stintel has quit [Quit: Bridge terminating on SIGTERM]
mglbg[m] has quit [Quit: Bridge terminating on SIGTERM]
humpelstilzchen[ has quit [Quit: Bridge terminating on SIGTERM]
jedertheythem[m] has quit [Quit: Bridge terminating on SIGTERM]
n00mann[m] has quit [Quit: Bridge terminating on SIGTERM]
tvall has quit [Quit: Bridge terminating on SIGTERM]
mighty17[m] has quit [Quit: Bridge terminating on SIGTERM]
humpelstilzchen[ has joined #maemo-leste
stintel has joined #maemo-leste
jedertheythem[m] has joined #maemo-leste
mighty17[m] has joined #maemo-leste
tvall has joined #maemo-leste
n00mann[m] has joined #maemo-leste
mglbg[m] has joined #maemo-leste
<rafael2k> I would also consider Palemoon as browser alternative, which still maintains gtk2 builds, alongside with gtk3 builds.
<rafael2k> and have read-made Debian 10 builds
<rafael2k> : )
<_uvos_> hows touch support
<_uvos_> the other mentioned browsers have very good support for touch gestures
<rafael2k> xorg updated - wow!
<rafael2k> _uvos_: not very good gesture support I guess... but it is considerably faster than ff or chromium
<rafael2k> I'm using it, but with mouse and keyboard
<_uvos_> not sure about faster
<_uvos_> on d4 ff is pretty mutch the faster browser by a large margine
<_uvos_> (scrolling speed wise)
<rafael2k> try palemoon
<rafael2k> it is faster, at least in the PP
<rafael2k> I'm using the gtk2 build, btw
<_uvos_> freemangordon: btw current cellulard/pinentry dosen reccognize when a puk is required (dont ask me how i know xD)
norayr has quit [Quit: Gateway shutdown]
dev has quit [Quit: Gateway shutdown]
<_uvos_> rafael2k: seams way slower than ff
<_uvos_> wierd, maybe beacuse d4 has a faster gpu than pp but a mutch slower cpu
norayr has joined #maemo-leste
<rafael2k> interesting
<rafael2k> anyone, both work fine here tbh
<rafael2k> *anyway
<rafael2k> a simple "top" measurement for opening "google.com", ff eats 24% of the system memory, while palemoon gtk2 9% (2GB total)
<_uvos_> top sucks at this because it fails to account for shared memory
Livio_ has quit [Ping timeout: 248 seconds]
<_uvos_> also ff holds buffers based on total memory size (yes this is really dumb)
<rafael2k> right, indeed... not a trustworthy method
<rafael2k> did not know about this in ff
<rafael2k> :/
<_uvos_> anyhow d4 total memory usage with ff loaded at google is 345 mb
<_uvos_> as a point of referance
<_uvos_> 32bit helps some here too ofc
<rafael2k> 366.4 MiB here
<_uvos_> for ff or system?
<rafael2k> ff
<rafael2k> 176.6 MiB palemoon
<_uvos_> my value was total system
<_uvos_> anyhow its fine
<_uvos_> both ;)
<rafael2k> indeed
<rafael2k> I'm using this to measure: https://github.com/pixelb/ps_mem
<_uvos_> rafael2k: yeah thats a good tool
<rafael2k> it really yelps : )
<rafael2k> btw, "sphone: route-pulseaudio: failure: Set sink to Earpiece No such entity"
<rafael2k> sphone: route-pulseaudio: failure: Set sink to Speaker No such entity
<rafael2k> sphone: route-pulseaudio: Seting route on alsa_output.1.stereo-fallback
<rafael2k> So no Speaker nor Earpiece entities in Maemo PP UCM config
<rafael2k> Also, who packaged the ring tune, packaged in the wrong location (my package was right...): sphone: playback-gstreamer: /usr/share/sounds/Nokia_tune.aac is not a valid file
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
<rafael2k> maemo-ringtones-mr0 <-- is the package wrong
uvos__ has joined #maemo-leste
<uvos__> alsa_output.1.stereo-fallback sounds like its the wrong audio device or?
<uvos__> alsa_output.1.stereo-fallback sounds like its the wrong audio device or?
_uvos_ has quit [Ping timeout: 260 seconds]
<uvos__> can you switch in pavucontrol-qt during a call
<uvos__> whats your default sink during a call?
<uvos__> (pactl info)
<rafael2k> yes
<uvos__> maybe also add pactl list to the bug
<rafael2k> btw, maemo-ringtones-mr0 changed /usr/share/sounds/Nokia_tune.aac to /usr/share/sounds/NokiaTune.aac dunno why... :(
<rafael2k> ok
<rafael2k> "Internal speaker" makes the audio out through the speaker
<rafael2k> (in pavucontrol)
<rafael2k> about the ringtone, any advice where to fix it? in the package or in the sound profile?
<rafael2k> ps: this was my package, as a reference: https://www.abradig.org.br/maemo-crazyness/maemo-ringtone_0.1-2_all.deb (which made my phone ring)
Livio has quit [Ping timeout: 265 seconds]
<rafael2k> btw, I'm debbuging libcamera in this issue: https://github.com/kbingham/libcamera/issues/28#issuecomment-1257167174
<rafael2k> still trying to have a clear picture with qcam...
<uvos__> rafael2k: yeah so the problem with the button in sphon ei ssimply
<uvos__> Default Sink: alsa_output.1.stereo-fallback is wrong
<uvos__> should be alsa_input.0.Voice_Call__hw_PinePhone_0__sink
<uvos__> so this is a pa setup issue, not related to sphone itself.
norayr has left #maemo-leste [Error from remote client]
<rafael2k> is it with my specific setup or with PP in general?
<rafael2k> (I mean, Maemo in PP setup)
<uvos__> well unless you changed something wrt that maemo on pp
<rafael2k> I did not afair
<freemangordon> chromium on d4 runs circles around FF
<freemangordon> to my surprise
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
<rafael2k> a couple of (still looking shitty) pics taken with qcam in maemo in PP: https://www.abradig.org.br/maemo-crazyness/test.jpg https://www.abradig.org.br/maemo-crazyness/test1.jpg
<freemangordon> nice :)
<rafael2k> one of libcamera devs (Kieran Bingham) is trying to help
<rafael2k> lets see if we get these problems squared out... then we'll have all the lower level plumbing done (including gstreamer sources!)
dev has joined #maemo-leste
rafael2k has quit [Ping timeout: 246 seconds]
dev has left #maemo-leste [Disconnected: closed]
dev has joined #maemo-leste
uvos__ has quit [Ping timeout: 250 seconds]
xmn has quit [Ping timeout: 248 seconds]
xmn has joined #maemo-leste
uvos__ has joined #maemo-leste
<uvos__> nice at pp images
<uvos__> i should try and get the front camera on d4 working some time
uvos__ has quit [Ping timeout: 250 seconds]
uvos__ has joined #maemo-leste
norayr has joined #maemo-leste
pere has quit [Ping timeout: 268 seconds]
norayr has left #maemo-leste [Error from remote client]
norayr has joined #maemo-leste
rafael2k has joined #maemo-leste
pere has joined #maemo-leste
rafael2k has quit [Ping timeout: 248 seconds]
uvos__ has quit [Ping timeout: 268 seconds]
uvos__ has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
<freemangordon> uvos__: re PUK - how to repro without blocking my SIM?
uvos has joined #maemo-leste
norayr has joined #maemo-leste
alex1216 has quit [Quit: WeeChat 2.3]
pere has quit [Ping timeout: 248 seconds]
<buZz> oh man, these typos get me everytime, what :D
<buZz> > sphone: sphone-conf: Could not get config key ExternalExec/CallAwnserd
<buZz> Awnserd? :D no wonder you cant find it, sphone-conf
Twig has joined #maemo-leste
<buZz> (btw, i'm having corona, hence my afk-ness)
<Wizzup> take care
<uvos> buZz: i hope you get better soon :)
<uvos> yeah idk what these sphone devs where thinking
<buZz> spellchecker too expensive ;)
Twig has quit [Ping timeout: 250 seconds]
Twig has joined #maemo-leste
pere has joined #maemo-leste
mardy has quit [Quit: WeeChat 3.5]
<buZz> uvos: sent a PR for correcting these :)
akossh has joined #maemo-leste
<uvos> freemangordon: hmm i cant repo the dimm problem
<uvos> freemangordon: so i wait until mce dimms
<uvos> then i "dbus-send --system --print-reply --dest=com.nokia.mce /com/nokia/mce/request com.nokia.mce.request.req_display_state_on"
<freemangordon> yes
<freemangordon> but, while it is dimming
<uvos> yeah
<freemangordon> did you repro?
<uvos> no
<uvos> so while its dimmed but not off
<uvos> i send that call
<uvos> this is the log i get
<uvos> mce: Received display on request
<uvos> mce: MCE_DISPLAY_ON in /build/mce-1.10.0+2m7/src/modules/display.c display_on_req_dbus_cb 446
<uvos> mce: inactivity: device inactivity timeout 30
<freemangordon> lemme try to repro here
<uvos> it also dosent missbheave in any way
<freemangordon> well, maybe because you are using different plugins
<uvos> ill mv my user ini
<uvos> sec
<freemangordon> or maybe recent fixes fixed it
<uvos> ugh
<uvos> x hanged
<uvos> well i never saw the issue
<uvos> so idk about recent fixes
<uvos> something about your setup vs mine is more likely
<freemangordon> my setup is vanilla
<uvos> sure
<freemangordon> yes, the issue is still there
<freemangordon> remember, you have to disconnect teh charger
<uvos> still rebooting
<freemangordon> did you upgrade x to latest?
<uvos> yeah
<uvos> *this
<uvos> sdl on drm also hits this
<uvos> so i doubt its xorgs fault
<freemangordon> never happaned here
<freemangordon> *happened
<freemangordon> ok, have to charge the batter a bit
<freemangordon> uvosL also, I think having 3 times --verbose on mce cmdline helps with recreating the ussue
<uvos> there is no verbose byond 2 times
<uvos> but ok
<freemangordon> well, I was running with 3 times
<freemangordon> maybe one was ignored, dunno
<uvos> yes it just decreases an int with no further effectr
<uvos> anyhow so now with default modules i cant repo either
<uvos> but no charger/usb let me get one
<freemangordon> it is not *that* easy
<uvos> (not that i know how it would make a difference)
<freemangordon> timing?
<uvos> idk how it would affect the timeing even
<uvos> mce dosent really care
<freemangordon> hmm, what the? now " display stays lit while on charger" actually works
<uvos> anyhow let me try
<uvos> thats wierd since the code in mce is gohne
<uvos> and nothing reads the corrisponding datapipe
<uvos> so it must be redundantly implmented
<uvos> (not a suprise theres quite some stuf rdeundantly implmented)
<freemangordon> yes, the issue is still there
<uvos> ok so plug in charger
<uvos> remove it? wait for dim?
<freemangordon> disable "lock screen automatically"
<freemangordon> maybe charger is unrelated
<freemangordon> hard to tell
<uvos> hmm
<uvos> cant trigger it
<uvos> still
<freemangordon> set timeout to 10 seconds
<uvos> yeah i have that
<uvos> display stays lit when charging is on on your end?
<freemangordon> no, it is onchecked
<freemangordon> so:
<uvos> i just triggered it
<uvos> by unchecking that
<uvos> no dbus required
<freemangordon> ok
<freemangordon> maybe
<uvos> so its something about exiting that mode
<freemangordon> I think dbus helps, but could be coincidence
<uvos> i cant make it happen again
<uvos> hmm
<freemangordon> yes, it it not easily reproducible
<freemangordon> that's why I think it is related to timing
<freemangordon> maybe changing gconf setting is related
<uvos> maybe but what would be changing gconf
<freemangordon> we, from the settings
<uvos> no
<freemangordon> dunno, just speculating
<uvos> those dont use gconf anymore
<freemangordon> ugh
<freemangordon> but what?
<uvos> theoreticly only mce should use its gconf keys
<uvos> ie its gsettings compliant
<uvos> they use the dbus interface to tell mce what to do
<freemangordon> how mce gets notified about the change? dbus?
<freemangordon> ttyl
<uvos> ttyl
Guest224 has joined #maemo-leste
<Guest224> I think that sept 25th stable release has security problem. It has at internet connection settings: Connect automatically Wi-fi...shoul it be Always ask...so that device doesn't go any open wi-fi:s automatically.
<Guest224> user can switch it automatically, if he/she wants later...but if user doesn't want..damage is done, if its default automatically.
<Guest224> ah..bad english...user can switch it to "connect automatically", if he/seh wants later...but if user doesn't want...dameage is done in first start up, if settings default is "connect automatically"
<uvos> connect automatically dosent mean it connects to any open wifi
<Guest224> ok..does it have to choose one time and then it goes it automatically?
<uvos> yes it connects to networks only if you connected to them before
<Guest224> thanks...good to know.
<Guest224> I also tested Pinephone docking bar with HDMI-output, but nothing happens...but should it even work yet with stable?
<Guest224> and I would test docking bar ethernet-port...any hints to good way to test?
<Guest224> 3G data-connection still need dev-image?
<uvos> yes
<uvos> hdmi out works
<uvos> but you have to set it up by hand
<uvos> via xrandr
<uvos> and hildon-desktop has bugs if the display changes size
<freemangordon> uvos: OTOH, I think mce should control kbd brightness better than it does now
<freemangordon> right now no matter what happens, kbd backlight is barely visible
<uvos> freemangordon: its user configurable
<freemangordon> leaving kbd useless in dark conditions
<uvos> imo its bright enough
<freemangordon> it is not
<uvos> but maybe d4s have variation
<uvos> anyhow i dehardcoded it
<freemangordon> here it is like it is off all the time
<uvos> its honstly quite bright here
<uvos> so thats wierd
<freemangordon> sec
<uvos> btw i found why display on while chargeing still wokrs
<freemangordon> here it is almost absolutely dark here and brightness is 80
<uvos> indeed its redundantly implemented in fremantle
<freemangordon> well, not that bad it seems :)
<uvos> something tells mce to stay on
<freemangordon> battery applet?
<uvos> via inactivity_mode_set_dbus_cb
<uvos> i have no idea whay
<uvos> t
<uvos> maybe
<uvos> anyhow i think the issue is
<freemangordon> you can dbus-monitor
<uvos> that timers dont get reset if the dbus call disables the inactivity block
<uvos> while dim
<uvos> but i cant make it happen again
<uvos> so hard to tell
<uvos> the brightness of the display and the keyboard are not directly related
<uvos> those are different tables
<freemangordon> sure
<uvos> btw
<freemangordon> the point is that 80 for dark room is not enough
<freemangordon> where is the table?
<uvos> well i think it is, but that a user prefeance thing
<uvos> mce.ini
pere has quit [Ping timeout: 250 seconds]
<uvos> so unplugging the usb creates activity
<freemangordon> I cannot find it there
<uvos> in mce
<uvos> so i gues it depends on if the dbus call comes before or after mce realises the usb gohne
<freemangordon> yeah, might be related
<uvos> maybe i should just remove this and have mce implement it again
<uvos> it seams wierd for mce to have all info needed
<uvos> but need some external tool to act on it..
<freemangordon> ok, where in mce.ini is that setting?
<uvos> oh nowhere sorry
<uvos> i forgot that i dehardcoded the brightness table for the display
<uvos> but not the one for the keyboard
<uvos> its in button-backlight.h
<uvos> needs the same treatment as the ex table in display.h then
<freemangordon> well, it seems there are 2 values only
<uvos> yes the keyboard is off
<uvos> beyond 1750000 lux
<uvos> backlight wise
<freemangordon> that's not ok
<uvos> ?
<freemangordon> as I said, kbd is useless for me in dim conditions
<uvos> why would it be on in the sun
<freemangordon> no need
<uvos> 1750000 lux is pretty bright
<freemangordon> then the table should be between 25 and 1750000
<freemangordon> ignoring higher readings
<uvos> no
<uvos> beacuse its user preferance
<freemangordon> why?
<uvos> someone might whant the keyboard light to be allways on
<freemangordon> ok, but default should be sane
<uvos> like on android
<uvos> its sane
<uvos> imo
<freemangordon> currently it is not
<freemangordon> no, trust me on that one
<uvos> so 1750 lux should be Overcast day;[4] typical TV studio lighting
<freemangordon> I can film you a video if you widh
<uvos> table is in mlux
<uvos> if something else is happening maybe your sensor is defective/ needs other callibration
<uvos> (calibration is in 70-droid.ini
<uvos> )
<freemangordon> what do you mean?
<freemangordon> the max brightness that can be set is 128,no?
<uvos> sure
<uvos> but thats quite bright
<freemangordon> not here
<uvos> (set it via sysfs)
<freemangordon> yes, that's what I did
<uvos> i dont know what to tell you
<uvos> i think its very bright, if you dont thats fine, ill dehardcode the table and you can set it to whatever you want
<freemangordon> also, it seems it never hits 128 here
<freemangordon> lemme check
<freemangordon> it does
<freemangordon> so, 80 is barely visible
<freemangordon> esp if you set display brightness to max
<uvos> 80 is farily dim but 25lux is very dark and the als cant realy mesure anything lower than that
<uvos> and i dont want it bright in a totaly dark room
<freemangordon> ok, but 250000 is too high threshold imo
<uvos> sure but at 200 ish lux it can be off anyhow
<freemangordon> so if you have indirect light (not sun) and display to max, kbd is not visible
<uvos> imo
<freemangordon> no, because you have reflections
<uvos> i dont see how you can have a high lux reflection
<freemangordon> from the buttons
<uvos> but not have lots of external lux on the keyboard
<freemangordon> of the keyboard
<uvos> they are matte
<uvos> i really dont follow
<freemangordon> not if they are used :)
<uvos> anyhow ill dehardcode the table
<uvos> and shure we can add a entry for 100lux
<freemangordon> tomorrow I'll capture a video to show you what I mean
<uvos> "Very dark overcast day"
<sicelo> incidentally, the buttons being too bright is the reason i disabled their lighting (and yes, i understand they only support On and Off)
<freemangordon> a couple of times it was impossible for me to write anything in a bar because I simply cannot see the letters
<freemangordon> sicelo: not really, this is how it is set now
<freemangordon> maybe really there are HW variants
<sicelo> i meant the touch buttons
<freemangordon> ah
<uvos> there ARE hw variants btw
<uvos> d4 hwA has a different keyboard
<uvos> (slightly)
<freemangordon> yeah, they are bright, but to me they are fine
<uvos> idk if it affects brightness
<uvos> those are way to bright for me
<uvos> i disabled those too
<freemangordon> touch buttons?
<uvos> like sicleo
<uvos> yeah
<freemangordon> not here
<freemangordon> look normal to me
<uvos> i think your eyes are simple different :P
<freemangordon> but, I keep display to max
<freemangordon> no, display is too bright here
<uvos> anyhow those buttons are 1 bit
<freemangordon> so, maybe display brightness shall affect kbd brightness as well
<uvos> mabye
<uvos> but lets dehardcode the table first
<freemangordon> ok
<uvos> its stupid anyhow
<uvos> since a different device will need different values
<freemangordon> in the meanwhile I will compile mce here :)
<uvos> it just so happens to work ok across d4 an and n900
dev has left #maemo-leste [Disconnected: closed]
<Wizzup> Guest224: re: eth, you can just manually bring it up
<Wizzup> we don't have a plugin for wired eth
<Guest224> ok
dev has joined #maemo-leste
Livio has quit [Ping timeout: 244 seconds]
<uvos> Wizzup: btw
<uvos> the icd dialog still hangs even now (where gprs usualy works)
<uvos> if gprs dosent work at that time
<uvos> (ie by not entering the pin for instance)
<uvos> or being out of range of a tower
<freemangordon> oh, which remindsm me that I shall fix that stupid limit for wpa pass length we have somewhere
<freemangordon> *reminds
Guest224 has quit [Quit: Client closed]
<uvos> i think this fixes the issue
<uvos> but its hard to be sure with the issue being so finiky to repduce
<freemangordon> mhm
Twig has quit [Ping timeout: 244 seconds]
pere has joined #maemo-leste
<uvos> buZz: thanks for the sphone pr
<buZz> yw :)
<buZz> i feel more might be coming in a while
<uvos> Wizzup: what happened to lel?
<uvos> buZz: how do you check the ofono sms qeue?
akossh has quit [Quit: Leaving.]
<uvos> ./list-messages i gues
<uvos> pending sweet
<uvos> i cant send sms anymore
<uvos> :(
<uvos> freemangordon: could you give me the ofono envvars for debuging at some point
<buZz> uvos: not list-messages
<buZz> sudo ls /var/lib/ofono/thatlongnumber/tx_queue -l | wc -l
<buZz> :D
<uvos> /var/lib/ofono/ is filled with long numbers for me
<uvos> anyhow list-messages shows my sms as forever pending
<uvos> so thats why it nolonger works
<uvos> probubly some new or now more severe ofono bug
<uvos> dosent matter if i restart or reboot
<uvos> no sms ever makes it
<buZz> uvos: only one of such dirs here
<buZz> afaik the number is the imsi, but not sure
<uvos> i have like 20 dirs in thre
<uvos> so if its imsi something is very wrong :P
<buZz> maybe you copied install around a lot? :P
<buZz> we already established your install is weird before, i think :D
<uvos> pff wierd :P
uvos has quit [Remote host closed the connection]
<buZz> ^_^
Pali has quit [Ping timeout: 246 seconds]
Pali has joined #maemo-leste
<Wizzup> uvos__: I guess lel died again
<Wizzup> sigh
lel has quit [Remote host closed the connection]
lel has joined #maemo-leste