uvos has quit [Read error: Connection reset by peer]
uvos has joined #maemo-leste
<Wizzup>
freemangordon: yeah reboot made it go away
<Wizzup>
freemangordon: really this is so nice, really smooth 3d, 2d, stable (it seems)
huckg has joined #maemo-leste
uvos has quit [Ping timeout: 256 seconds]
huckg has quit [Quit: Client closed]
jk_ has quit [Quit: Leaving]
TonyStone has joined #maemo-leste
TonyStone has quit [Remote host closed the connection]
TonyStone has joined #maemo-leste
TonyStone has quit [Quit: Leaving]
TonyStone has joined #maemo-leste
Pali has quit [Ping timeout: 240 seconds]
cockroach has quit [Quit: leaving]
macros_ has joined #maemo-leste
macros__ has quit [Ping timeout: 268 seconds]
xmn has quit [Ping timeout: 256 seconds]
joerg has quit [Ping timeout: 240 seconds]
joerg has joined #maemo-leste
<mighty17[m]>
`[ 43.466] (EE) AIGLX error: dlopen of /usr/lib/xorg/modules/dri/swrast_dri.so failed (Error loading shared library /usr/lib/xorg/modules/dri/swrast_dri.so: No such file or directory)` there is swrast.so, should i just rename it?
* mighty17[m]
hasnt set MESA_LOADER_DRIVER_OVERRIDE=pvr for xorg
<freemangordon>
hmm, ants are still there, but besides that and tearing I think we have a pretty descent GPU stack now
<freemangordon>
tmlind: ping
<freemangordon>
Wizzup: I guess you don't mind if I move sgx-ddk-um to autotools?
uvos has joined #maemo-leste
<mighty17[m]>
<mighty17[m]> "hasnt set MESA_LOADER_DRIVER_OVE..." <- That didn't work as well
<mighty17[m]>
swrast_dri.so is necessary?
<uvos>
aiglx is never going to work on pvr
<uvos>
aiglx: acellerated indirect opengl for x
<uvos>
1. indirect rendering is disabled by default in x since 2016 or so
<uvos>
2. omap4 dosent support opengl
<uvos>
3. aiglx supports opengl up to version 1.2 only
<uvos>
4. no one uses opengl 1.2
<Wizzup>
freemangordon: don't mind
<uvos>
5. except for special niche uses (like me remote rendering cnc program tracebacks over the network) aiglx is useless
<mighty17[m]>
aiglx is related to my issue? :O
<uvos>
aiglx is trying to load swrast_dri
<uvos>
this is red herring
<mighty17[m]>
Ah, I wonder why it's used in lxqt then
<uvos>
its not used
<uvos>
its just loaded
<uvos>
its totaly unrealted to any problems you might have
<uvos>
aiglx is _never_ used
<mighty17[m]>
Imma send full log then
<uvos>
unless you enable it explicitly in like 3 places
<freemangordon>
OTOH I don;t really think his arguments are valid, but I am not sure I can convince him
<freemangordon>
*Tomi
<tmlind>
freemangordon: not sure i can help much with that one
<freemangordon>
well, without this omapdrm is more or less useless for anything else but a simple usecases
<freemangordon>
esp n omap3
<freemangordon>
*on
<freemangordon>
without that all GEM buffers must be allocated from CMA, otherwise they cannot be exported == PVR cannot render to them
<freemangordon>
and given that CMA is unreliable...
<tmlind>
ok
<freemangordon>
tmlind: I am asking you because I know what the result be if I send that for upstreaming
<freemangordon>
an instant NAK
<freemangordon>
without even a discussion why and how
<freemangordon>
I am not sure it will be the same if you send it
<freemangordon>
but well...
<tmlind>
heh i doubt me sending it makes any difference :)
<freemangordon>
well, I bet it makes
<tmlind>
best to have some clear test case in the description
<freemangordon>
what do you mean? I don't think a test case is needed to prove that non-linear buffers are not exported. There are checks in current (upstream) code to assure that, -22 otherwise
<tmlind>
how about some memory usage comparison in the description?
<tmlind>
i guess on n900 it makes a difference
<freemangordon>
I can do tiler_map comparison on d4, but it will be huge
<freemangordon>
it makes all the difference on d4 as well
<Wizzup>
hmm my X seems stuck here: [pid 3721] ioctl(12, DRM_IOCTL_MODE_SETPROPERTY, 0xbe85c978) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
<Wizzup>
no error in dmesg
<Wizzup>
uvos: ok will merge
<freemangordon>
ugh, libtool does not allow library revision to be > 99999 :(
<freemangordon>
cool, I have no clue what is this about :)
<uvos>
not sure what you mean
<uvos>
in pvr_k?
mepy_ has quit [Remote host closed the connection]
<freemangordon>
in geberal
<freemangordon>
*general
<uvos>
pvr_k checks the version
<uvos>
but it just gets it form some funciton
<uvos>
i dont think the file name matters
<uvos>
just what pvr_um reports
<freemangordon>
no, I am talking about versions of the libs
<freemangordon>
if I compile to lib.so.1.2.0 and later on rename to lib.so.1.2.3, does it change anything?
<freemangordon>
besides symlinks, obviously
<uvos>
pvr specificly? no
<uvos>
other libs sure
<uvos>
pretty sure i renamed some stuff while testing different variants
<freemangordon>
"other libs sure" - what do you mean?
mepy has joined #maemo-leste
<uvos>
wel obviously it can not be stated generally that compiling as 1.2.0 and renaming the lib later to something else is equivalent as passint something else to the build system
<uvos>
since plenty of libs use the version string
<freemangordon>
yes, but I am talking about revision, not version
<freemangordon>
the '0' at the end
<uvos>
same thing
<freemangordon>
but, does this get included anywhere else, but in the name?
<freemangordon>
basically this is the question
<uvos>
question is essantally unawnserable since doing so would force me to prove a negative
<uvos>
so no idea
<uvos>
you certenly could do this
<freemangordon>
yeah, my question was rather "do you know".
<freemangordon>
no need to prove anything
<freemangordon>
I'll do it to work, if we hit issues, well
<sicelo>
anyway, maybe yours will work better for new users
<dsc_>
mine can be described as a Google Authenticator clone
<dsc_>
GUI wise
<dsc_>
ill push it to git sometime and ping you I guess
<dsc_>
we can have both
<dsc_>
ヾ(⌐■_■)ノ♪
<sicelo>
yes, users will appreciate it
<sicelo>
i'm not going to switch myself tbh ... because i already have years of keys in the format of this one :-)
<sicelo>
it has a big limitation in that you have to convert the code first, so yes, for most new users it's a great PITA. i think yours will therefore be the better one
<sicelo>
cool. yes, only totp seems to be in use nowadays
<dsc_>
right
<dsc_>
I wondered that :P
pere has joined #maemo-leste
<sicelo>
dsc_: question though - why something from scratch?
<dsc_>
I tend to start projects without checking if it existed already :/
<dsc_>
tbh I wanted to make a 2FA app anyway for my Ubuntu desktop :P
<dsc_>
and then I was like "I should port it to leste"
<dsc_>
been only working on this for a few days though...
<dsc_>
so regardless if its handy for leste, I want a Google Authenticator-like app for my Ubuntu laptop
<freemangordon>
Wizzup: do you know how to mv in Makefile.am install-exec-hook?
<freemangordon>
I mean - what is the 'canonical' way?
<Wizzup>
sorry, don't know what you want exactly
<freemangordon>
to rename a file
uvos has quit [Quit: Konversation terminated!]
<sicelo>
dsc_: sure, please port it :-)
<sicelo>
i think i'm the only user of the one i ported, so effectively there isn't one for Leste
<dsc_>
sicelo: so turns out the options are kind of limited for OTP GUIs on linux, which surprised me. Granted, having 2FA codes on your desktop defeats the purpose, but still.
<Wizzup>
dsc_: probably they all use android ;)
<sicelo>
i see two GTK ones in sid
<sicelo>
i think you're a Qt guy .. ;-)
<dsc_>
well as a user I wouldnt care
<dsc_>
you're right, `otpclient` seems to work fine
<sicelo>
gnome-authenticator and otpclient ... i haven't used any of them
<sicelo>
but don't get me wrong - i wasn't saying don't write one ... was just asking
<sicelo>
i don't even know how these work on Leste (for obvious reasons)
<dsc_>
But, for example, this `otpclient` might look scary to new users, it's more of a power-user tool. We need to bring Linux to the desktop in 2022. All GUIs need to have 3D particle explosions to wow the crowd.
<dsc_>
therefor I will continue my efforts.
<dsc_>
therefore*
<bencoh>
as long as the particle explosions can be disabled .... :)
<dsc_>
:D
<bencoh>
I'm half-serious :)
<sicelo>
20:26 < dsc_> base32 (QR) codes ... you're saying it only takes QR codes?
<dsc_>
sicelo: Yeah QR code via webcam or desktop screenshot
<dsc_>
(or phone camera)
<sicelo>
i hope you'll also support text entry (of the code/string)
<sicelo>
because on Leste, for example, juggling a screenshot is less easier than copying the code onto clipboard, then pasting ;-)
<dsc_>
indeed, will do. Google Authenticator also supports this. So my app will at least be on-par regarding capabilities with that one
<dsc_>
but it wont be as feature rich as yours
<sicelo>
heh, this one is quite bare, and no casual user is even able to make it work
<dsc_>
ill try yours in a bit
<sicelo>
it's specifically for Hildon (and i didn't write it ... just ported it)
<dsc_>
cool
<dsc_>
yeah next time ill ask here before writing something lol
<freemangordon>
uvos: no idea what did you do, but since yesterday leste refuses to charge here
<freemangordon>
I am booting with cable connected to fastcharger (after power-down because of a low battery), it boots to h-d (maybe) and then instantly beeps and powers-down
<freemangordon>
on d4 that is
uvos has joined #maemo-leste
<uvos>
freemangordon: yes thats expected
<freemangordon>
oh, now I feel better :D
<uvos>
it was a temporary situation because the charge mode pr was merged later
<uvos>
just boot emergency mode
<uvos>
it will charge there
<freemangordon>
I boot to android
<uvos>
sure that works too
<uvos>
this issue is now fixed
<freemangordon>
and it charges there, but android says 15% full
<freemangordon>
fixed how/where?
<uvos>
with Wizzup merging the pr just now
<freemangordon>
ah, ok
<freemangordon>
what is the fix?
<uvos>
enabling charge mode
<uvos>
so that this works as designed
<freemangordon>
hmm, android just boots
<uvos>
ie stays in charge mode at least untill the battery is safe to boot
<uvos>
hmm?
<uvos>
it dosent boot to kexecboot?
<freemangordon>
it boots and then I select 'android'
<freemangordon>
and it boots there, which means battery has enough charge
<freemangordon>
15%
<freemangordon>
some limit is not quite right
<uvos>
no its fine
<freemangordon>
how's that?
<uvos>
its just more conservative than android
<uvos>
beacuse 1. we take longer to boot 2. android takes the battery down to 3.0v
<uvos>
which is pretty bad for it
<freemangordon>
as I said it boots to h-d
<freemangordon>
but refuses to charge and instead powers down
<uvos>
and 3 we can only take 500mah form usb
<uvos>
android can take 1.5A
<uvos>
*500mA
<uvos>
these 3 factors allow android to boot way sooner
<freemangordon>
what do you mean "usb"? this is not USB but fastcharger
<uvos>
dosent matter
<uvos>
mainline kernel has no way to detect this
<freemangordon>
wait, you are saying we are limited to 500 mA?
<uvos>
or negotiate for high power device class
<uvos>
yes we are
<freemangordon>
omg
<uvos>
even that is a hack
<freemangordon>
this is useless, basically
<uvos>
we dont negotiate for high power
<uvos>
so we violate usb spec
<uvos>
we should only take 500uA
<uvos>
i would not call it useless
<uvos>
it just takes longer
<freemangordon>
no, because you cannot use your device for how many minutes? 10?
<uvos>
no
<uvos>
just 2 minutes or so
<freemangordon>
also, you cannot use your device while charging with low battery
<freemangordon>
as it drains the battery instead of charging it
<uvos>
in my experiance you can
<uvos>
as long as your not loading it hevly
<uvos>
ie compiling is out
<freemangordon>
yeah
<uvos>
but webbrowsing is fine
<freemangordon>
who should fix this charging thing?
<freemangordon>
there are no low battery warnings at all
<uvos>
it unimplemented, not broken
<freemangordon>
at some point device just powers down
<uvos>
there are low battery warnings
<uvos>
no
<uvos>
or yes
<freemangordon>
no, there are not
<uvos>
yes there are
<uvos>
its just
<uvos>
that due to how cpcap works
<uvos>
you cant know what state of charge the battery is in
<uvos>
unless you see the battery full during that boot
<uvos>
and charge estimation from voltage in upower is terrible
<freemangordon>
and what about upower?
<uvos>
to the point of uselessness
<uvos>
so it thinks the battery is at 40% charge while it has a resting voltage of 3.2 or something
<uvos>
if there is adquate current
<freemangordon>
useless or not, it is better to give 10 fake low battery warnings than no warning at all and power-down out of the blue
<uvos>
upower needs the kernel to report charge staten wich cant unless you see the battery full during that boot
<uvos>
or it needs to estimate
<uvos>
witch it dose, very poorly
<uvos>
freemangordon: your welcome to improve it :P
<freemangordon>
yeah
<freemangordon>
before latest change it was doing pretty much ok
<freemangordon>
now this is useless
<freemangordon>
it at least was allowing me to boot to h-d and charge
<freemangordon>
and actually use the device
<freemangordon>
now it does not
<uvos>
"my latest change" ensures the battery dosent dicharged below 3v
<uvos>
wich was routinly happening
<uvos>
and runined one of my new batterys
<uvos>
so yeah im not removing that
<uvos>
it works fine
<sicelo>
:)
<uvos>
(with charge mode enabled)
<freemangordon>
uvos: the easiest way to ensure that is to not turn on the device, no?
<uvos>
you cant this is set by the bootloader
<freemangordon>
sure i can, by simply not pressing the power buttonj
<uvos>
i also can avoid geting into a car accident by handing myself
<freemangordon>
anyway, I think we need to have a discussion soon on what quality we want to produce
<freemangordon>
i.e. are we happy with things that works when the planets are aligned
<freemangordon>
but only then
<uvos>
this is a silly discussion to have
* freemangordon
is afk
<uvos>
no one wants these imperfect solutions
<uvos>
its just a question of what you want to work on to improve
<Wizzup>
freemangordon: do you know where the tp account manager info is stored in fremantle
<Wizzup>
freemangordon: just mission control stuff I guess
<freemangordon>
umm, in the same place as in upstream
<freemangordon>
what in particular do you need?
<Wizzup>
just want to look around, see what params are used for telepathy-idle on my fremantle n900
<freemangordon>
ah
<freemangordon>
it should be in /usr/share/telepathy
<freemangordon>
iirc
<Wizzup>
user accounts?
<Wizzup>
ok I didn't mean this, but this is also helpful
<sicelo>
mc-tool list
<sicelo>
then mc-tool show <account ...>
<Wizzup>
freemangordon: as in it is not in .config
<freemangordon>
hm,, it should be in .config
<freemangordon>
is it not?
<Wizzup>
sicelo: hm I don't have mc-tool
<Wizzup>
freemangordon: well let me dig
<sicelo>
oh, maybe you need to install it. i've always had it on my N900 and thought it came ootb
<freemangordon>
Wizzup: .local/share?
<sicelo>
mc-tool comes from libmissioncontrol-utils
<freemangordon>
I forgot where addressbook was kept
<Wizzup>
.rtcom-accounts
<Wizzup>
seems more like nokia specific way of storing the info though
<Wizzup>
as in I doubt that missioncontrol reads that
<freemangordon>
I think those are not mc accounts
<freemangordon>
this is different to mission-control, iiuc
<freemangordon>
not sure though
<Wizzup>
well mission-control is just account manager and channel dispatcher
<Wizzup>
maybe you call account manager where to read accounts from or something
<Wizzup>
maybe you can tell*
<freemangordon>
no idea
<Wizzup>
freemangordon: probably they parse it in rtcom binaries and just initiate Connection with those params from it
<Wizzup>
at connmgr
<freemangordon>
could be, yeah
pere has quit [Ping timeout: 256 seconds]
<freemangordon>
uvos: device just powered down after sitting almost idle on the charger since we talked. maybe you ramp-up patch doesn't play well with the charger I have here
<freemangordon>
but it was wotking ok before
<Wizzup>
it improved the situation for me (no flickering when I plug it into a device), but of course it might be different for different devices/cables/chargers
<uvos>
was the green light on?
<freemangordon>
no
<Wizzup>
although the status not updating is annoying, since that impacts upower and also mce
<uvos>
then it wasent charging
<freemangordon>
yes
<freemangordon>
it wasnt
<uvos>
the green light is 100 hw indicator
<uvos>
*100%
<freemangordon>
sure
<freemangordon>
it was turning green before
<uvos>
the issue the ramp up fixes is pretty easy to see on a scope
<uvos>
cpcap will turn off charging if the voltage ever dips below a certain threshold
<freemangordon>
I don;t argue it it fixes issues or not
<uvos>
with quite high bandwith
<freemangordon>
nut since yesterday my device refuses to charge under leste
<uvos>
so if it stoped charging this happend
<Wizzup>
freemangordon: what is the problem you are seeing now, that it doesn't charge with new patches?
<freemangordon>
yes, it does not charge
<freemangordon>
oh, now it turned green
<freemangordon>
(the light)
<freemangordon>
after restart
<freemangordon>
and I got "charging" yellow stripe
<freemangordon>
no idea what's going on
<uvos>
the patch has also been in kernel longer than yesterdat
<uvos>
*day
<uvos>
afaik
<uvos>
but i dont use leste kernel
<freemangordon>
and now there is indication in the status bar that it charges
<freemangordon>
weird
<uvos>
sure that usually works
<Wizzup>
freemangordon: yeah so the delay there I think is a 30s one, which is when upower polls
<uvos>
sometimes it fails tho
<freemangordon>
not since yesterday
<freemangordon>
till 2 minutes ago
<uvos>
sometimes its immidately recognised
<freemangordon>
it was not recognized at all
<freemangordon>
but yeah, lets see
<freemangordon>
maybe some HW weirdness
<freemangordon>
uvos: could it be that android had put it in some weird state?
pere has joined #maemo-leste
<uvos>
mabye - probubly not
<Wizzup>
freemangordon: so it looks like for tp we will need a program that starts tp connections on protocols/accounts. basic one is a ring connection for tel protocol
<Wizzup>
but something must request the account for sms to come in
<Wizzup>
I suppose whichever program requests it will also log?
<Wizzup>
or do we want a separate account for logging
<Wizzup>
I think nokia decided to combine these things
<Wizzup>
so if I had to guess, rtcom-call-ui sets up tp account with channels for calls, and rtcom-messaging-ui sets up tp account with channels for text(s)
<Wizzup>
and both do rtcom logging
<Wizzup>
(that is, the ui processes)
<freemangordon>
Wizzup: I am almost sure all this is explained on maemo.org wiki
<Wizzup>
I am pretty sure I know how it works, it was a question for how we want to do it
<Wizzup>
but if you want to link me maemo.org wiki pages, that'll be helpful I guess
<freemangordon>
ah, it is fine, I mean - if you know how it works, ok
<Wizzup>
I don't like the idea of requiring a GUI to log
<Wizzup>
but it probably makes the most sense since we need something to 'request' telepathy to start the so-called connection managers
<Wizzup>
(and connections on those connection managers)
<freemangordon>
I think nokia did a good job there
<Wizzup>
like, telepathy-ring is a connection manager and to receive smses (and have telepathy-ring run at all) we need to request an account on it with protocol 'tel'
<freemangordon>
so maybe do it like they did
<Wizzup>
k
<Wizzup>
ok
<uvos>
sphone can run without gui now btw, we could easly implment the logging as a sphone module and then spwan one non gui sphone process for logging or only one process with logging and ui loaded as desired
<uvos>
as everything is a module you can pick an choose what process dose what
<Wizzup>
right, but the fact that something must for example request a ring account means that whichever requests it can also do the logging
<Wizzup>
we could separate the logging, but programs also need to request connections so that they can act on incoming messages
<Wizzup>
or send messages
<Wizzup>
i.e. even if conversations mostly just reads from a db now, it must be able to send message
<Wizzup>
messages
<uvos>
sure
<Wizzup>
and to do it that it must talk to telepathy, request connections, and manage those connections, and create (or 'ensure') channels on those connections
<uvos>
im just saying that sphones arch makes it easy to implement the "monlithic" nokia esque shortcut way now
<Wizzup>
so we -could- have a module that just onlines/activates connections
<uvos>
and implement something better later
<Wizzup>
and another module that just does logging
<uvos>
without throwing most of it out
<Wizzup>
but it might not make sense that way
<Wizzup>
uvos: sure, I'm still just understanding telepathy
<Wizzup>
not making 'design decisions' in that sense yet
<Wizzup>
tp also has different client types: observers, approvders and handlers
System_Error has joined #maemo-leste
mepy has quit [Remote host closed the connection]
mepy has joined #maemo-leste
inky has joined #maemo-leste
akossh has joined #maemo-leste
elastic_dog has quit [Read error: Connection reset by peer]
elastic_dog has joined #maemo-leste
elastic_1 has joined #maemo-leste
elastic_dog has quit [Read error: Connection reset by peer]
elastic_1 has quit [Read error: Connection reset by peer]
elastic_dog has joined #maemo-leste
akossh has quit [Quit: Leaving.]
<uvos>
ugh
<uvos>
the maemo volume buttons switch between portrait and landscape
<uvos>
without a config option
<uvos>
terrible ux
<uvos>
first rule of buttons: muscle memory works if they dont change function
<Wizzup>
uvos: who intercepts this then?
<Wizzup>
uvos: on the n900 this works really well fwiw
<uvos>
android used to do this
<uvos>
and i hated it
<uvos>
anyhow
<uvos>
its implmented in the volume applet
<uvos>
btw the volume applet should work fine with the current ucm setup
<uvos>
you should only have to change /usr/share/maemo-statusmenu-volume/volume_steps_update
<uvos>
to point to the correct sink
<uvos>
unfortionatly it dosent work atm
<uvos>
but that just looks like a pa api change
<Wizzup>
wait you have volume applet working?
<uvos>
yes
<Wizzup>
let me send you some beers :)
<uvos>
heh
<Wizzup>
with our existing pa setup?
<uvos>
yes
<uvos>
its just a tiny change
<uvos>
and that config change
<uvos>
but let me clean it up
<Wizzup>
ok
<uvos>
also the f7 f8 thing..
<uvos>
i just replaced that atm
<Wizzup>
yeah, let's not get into that now but well noted
<uvos>
heh
<uvos>
what you dont want me flaming for 30 minutes about keymappings?
<Wizzup>
well we've gone over that stuff a few times and realised that it is fubar no matter
<uvos>
not really
<uvos>
but ok
<uvos>
not now
<Wizzup>
:)
<uvos>
correct sink is alsa_output.0.HiFi__hw_Audio_0__sink btw
<uvos>
(should be on all devices)
<uvos>
(except n900)
<Wizzup>
we might need to make volume_steps_update a leste-config file then, or figure out how to deal with it
<Wizzup>
maybe if we give n900 UCM file
<uvos>
also not sure how to deal with hdmi audio
<uvos>
the thing is somewhat unfortionatly hardcoded for 2 channels
<uvos>
droid 4 might have up to 6
<Wizzup>
I plan to worry about hdmi and external screens quite a bit later down the road
<Wizzup>
I'd have to check how the n900 deals with it, but I suspect it's probably on the headphone mapping
<uvos>
sure
<Wizzup>
(since on the n900 the external screen clone is through the hp jack)
<uvos>
its also just 2 channels
<uvos>
so theres nothing to handle
<Wizzup>
hm, what other channels?
<uvos>
n900 dosent have otg and dosent have hdmi
<uvos>
ergo no audio output > 2 channels is possible
<uvos>
ergo nokia dident care
<Wizzup>
right
<Wizzup>
my point was mostly that 'how do I control hdmi audio when I use an external screen, possible not even cloned' is not high on my priority/worry list
<Wizzup>
anyhow I am happy currently because I think I understand telepathy well enough now
<uvos>
granted
<Wizzup>
of course my confidence will tank when I start writing the code, but I think I'll get through it