<freemangordon>
Wizzup: In that regard - how does wpa_supplicant support powersave and BT coexistence?
<freemangordon>
also, how is TX power controlled?
<freemangordon>
ah, and what about regulatory domain change (country code change)?
<freemangordon>
After looking in wlancond code, I tend to agree we shall not use it as it does lots of stuff, but, I still think we need a kind of a proxy that controls the access to wpa_supplicant
<freemangordon>
and listens to cell registration change and BT status changes
mardy has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
Wizzup: just wondering, did you seriously examin just ditching icd2 and porting the ui bits to networkmanager with modemmanager in the past? as this supports everythin we would need as far as i can tell and works pretty great as a base for plamo-nm (conectivity ui) and is also used by phosh (havent tried it there).
<uvos>
dealing with all the cases wifi/cellular/various tunnels nm supports in icd seams like a tall order for our manpower...
<freemangordon>
uvos: Does NM solves the issues I raised ^^^?
<uvos>
sec i have to read the backlog
<uvos>
it dose have a interface for wifi tx power
<uvos>
and you can set it per connecction profile it seams
<uvos>
i obviously support bt pan networks to
<freemangordon>
the point is that this seems to be related with BT coexistence, at least on wl1251, I doubt NM cares about BT
<uvos>
im not sure what you are looking for with coexistance
<uvos>
device power activation?
<freemangordon>
yes
<uvos>
ie power the wifi chip if we need bt
<uvos>
?
<uvos>
ok
<freemangordon>
or rather the power savings level
<freemangordon>
this could be wl1251 specific only though, but still
<uvos>
i think this is the kernels job
<freemangordon>
it seems wlancond listens for BT changes and limits the level of power savings
<uvos>
ok
<uvos>
so at aleast on the maphones this "just works"
<freemangordon>
uvos: setting the level of powersaving is not kernel's job
<uvos>
ie the kernel wakes the device is you start using the bt interface
<freemangordon>
isn't that related to TX power as well?
<uvos>
im not sure what you mean by level of powersaveing, the radio can be on or off
<uvos>
and the kernel holds tx power for bt
<uvos>
and for wlan
<freemangordon>
actually it seems it can be more than that
<uvos>
and the device switches depening on what its doing transperantly
<uvos>
yes the kernel dose this on the mapphones, there are various power states the device cycles through depending on how long its not been needed for a pacaket
<uvos>
(or rather the wifi fw)
<uvos>
this is configurable in the nvs to a degree
<uvos>
kernel also has interfaces to make this more agressive
<uvos>
but this dosent work with driver we use for the wl chips
<freemangordon>
exactly: who uses those interfaces?
<uvos>
ok
<freemangordon>
or rather - who is supposed to
<uvos>
you can just turn it on
<uvos>
its on by default i think even
<uvos>
have to check
<freemangordon>
how? via cli?
<uvos>
iw can do it i
<freemangordon>
same
<freemangordon>
I mean - we want good ux, no?
<uvos>
freemangordon: sure but you can just turn this on
<uvos>
there is no real down side
<uvos>
it makes the device take a bit more time to respond if its asleap
<uvos>
the user never has to care about this
<freemangordon>
I still wonder why nokia is doing that control explicitly
<uvos>
and on mapphones its allways on anyhow
<freemangordon>
I mean - there must have been a reason
<uvos>
because the fw dose it there
<freemangordon>
BTW, we still need someone to deal with regulatory domain changes
<uvos>
freemangordon: maybe so idk
<uvos>
freemangordon: ill check nm interfaces for that
<uvos>
se
<uvos>
c
<freemangordon>
no, my question was rather: Who listens to country code change and sets regulatory domain?
<freemangordon>
the interface used to set that domain is not relevant
<freemangordon>
uvos: Please share if you find something, in the meanwhile, I have to do some RL work, sorry, bbl
Pali has joined #maemo-leste
diejuse has joined #maemo-leste
pagurus has joined #maemo-leste
<parazyd>
Wizzup: We can build wpa_supplicant of course.
<parazyd>
Wizzup: Regarding Pinetab, I think you have the earliest possible version.
Daanct12 has joined #maemo-leste
Daanct12 has joined #maemo-leste
Daanct12 has quit [Changing host]
Evil_Bob has joined #maemo-leste
diejuse has quit [Quit: Leaving.]
diejuse has joined #maemo-leste
<Wizzup>
parazyd: re: pinetab, it broke since the last update
<Wizzup>
freemangordon: regarding tx power and power saving, I figured that would maybe go in libicd-network-wpasupplicant
<Wizzup>
uvos: we considered it only lightly a few years ago
<Wizzup>
uvos: the trouble is we have to re-write a lot of our interfaces for it
<parazyd>
Wizzup: It loads some dtb though, right?
<Wizzup>
parazyd: yes, the pintab
<Wizzup>
I changed the boot.scr to load it
<Wizzup>
parazyd: I created issues on github :p
<parazyd>
ok, I'll check
<parazyd>
Thanks
<Daanct12>
Good afternoon
<Wizzup>
hi
<Daanct12>
How's everyone?
* Wizzup
is waking up
<uvos>
Wizzup: porting the ui might be less work than trying to reimplment all nm features in icd
<Wizzup>
uvos: I agree it would be a good to benefit from the NM work, but NM also wants modemmanager and there are some other complications
<Wizzup>
I think it would make more sense to look at this at a later time
<Wizzup>
in my personal experience NM just has its own will, but maybe it got better in the last few years
<Wizzup>
uvos: a later time, as in, when we have a more or less complete phone os
<tmlind>
Wizzup, uvos: fyi, i got the utagboot and droid4-kexecboot stuff mostly updated for supporting xyboard too, still need to test
<Wizzup>
tmlind: oh sweet... :)
<uvos>
no fair i wanted to do that :D
<uvos>
nice :)
<Wizzup>
uvos: I feel that it makes sense to get some of the nokia bits in place without investing too much time. the initial icd2 investment we already did (fmg REd it, I did the wpasupplicant plugin)
<tmlind>
hmm i kind of need a binary dump of the mz609 utags partition to add support for that, probably the same as on mz619 but just in case
<Wizzup>
it's also somewhat neat to be able to control and change what it does relatively easily, but if we get to the point where NM has solved all the problems are trying to solve, then yeah, it's worth considering for sure
<uvos>
the inital investment should count for nothing
<Wizzup>
uvos: but for example I don't think NM works well with ofono at all
<uvos>
sunk cost falicy and sutch
<Wizzup>
uvos: point is it's already done, we can't take it back :p
<Wizzup>
uvos: I think there might be some merit, but I'm personally like to direct my time on other stuff (merging your mce stuff, getting ofono mce plugin in place), audio, and some stuff for parazyd
<uvos>
okok
<Wizzup>
like, clearly there is probably merit, but a lot of maemo is built around icd2
<uvos>
i was just mentionig it
<Wizzup>
s/probably//
<uvos>
its your domain
<Wizzup>
check
<uvos>
(network stuff)
<Wizzup>
lucky me :p
<Wizzup>
check @ just mentioning, just trying to explaining my thought process
<Wizzup>
tmlind: let me know if you need anything from me, I have the tablets here
<tmlind>
hmm well i found my old utags mmcblk1p6 dump from mz609-32m
<uvos>
Wizzup: a "soft" way of supporing nm would also be to support xdg StatusNotifierItem in hildon desktop
<uvos>
then we could eventually just replace the maemo ui with something else
<uvos>
maybe phosh's ui
<tmlind>
Wizzup: i guess you could try flashing one to xyboards after i manage to push out the files, full battery and root access for dd is needed, risky as there may be no way to reflash the utags unless allow-mbmloader-flashing-mbm.bin is found..
<tmlind>
uvos: plenty of stuff for you to hack left there :)
<uvos>
tmlind: :)
<tmlind>
i just wanted to clean up my old hacks so i can push them out
<uvos>
ofc i was just kidding around
<tmlind>
uvos: yes :) and i added machine detection to droid4-kexecboot if you still need some xt875 options
<uvos>
ah nice
<uvos>
yes we should hide the boot to stock option there
<tmlind>
seems we can do it based on /proc/device-tree usb_id entry
<tmlind>
looks like i pushed out my local hacks and my old wlan configuration earlier this year to the old branch so it's kind of trashed :)
<tmlind>
uvos: so hopefully the kexecboot related changes do not break your mainline kernel support for xt875. i tested the built kexecboot image works on xt894 and mz619
<Wizzup>
freemangordon: country/Country in wpa_supplicant
<Wizzup>
tmlind: that patch is on top of what branch? 5.13?
<tmlind>
Wizzup: seems i broke it in v5.12
<Wizzup>
ah
<tmlind>
finally the fun part :) i'll try to configure the lcd for mz619 for kernel
<Wizzup>
:)
<tmlind>
uvos: looks like i only have a minimal dts file for mz619 with some earlier lcd timings in it that did not work
inky has quit [Ping timeout: 268 seconds]
<uvos>
tmlind: check
diejuse has joined #maemo-leste
hi^-^ has left #maemo-leste [Leaving]
<freemangordon>
Wizzup: sure, but who is going to call this when phone registers so we can get cell info (and thus detect which country we're in)?
<freemangordon>
I doubt wpa_supplicant is registered with ofono signals
<bencoh>
are you referring to enforcing local wireless restrictions?
<bencoh>
(iwreg?)
<freemangordon>
yes
<Wizzup>
freemangordon: typically I think they figure it out by the aps that around them
<Wizzup>
that are*
<bencoh>
Wizzup: sounds like magic to me :)
<Wizzup>
not sure if wpa_supplicant does it itself
<Wizzup>
bencoh: mhm, maybe not :)
<Wizzup>
freemangordon: whatever we decide manages the ofono state I guess
<Wizzup>
e.g. what powers the modem on/off, deals with online sim replacement, maybe gets the time as well
<freemangordon>
so, you change restrictions *after* you already sent packets on channel 13 while in EU? (just an example, don;t really remember what channels were forbidden where)
<Wizzup>
no idea, I never change it and always blast standard region
<Wizzup>
works well :)
<freemangordon>
but is illegal
inky_ has quit [Read error: Connection reset by peer]
<Wizzup>
I already answered the question above in any case ;)
<freemangordon>
or, possibly could be
<freemangordon>
let me see if I get it right - you object having another daemon that takes care of regulatory domain, and acting as a proxy between icd2 plugin/connui and wpa_supplicant, synchronizing access to it?
<freemangordon>
because this looks to me the most sane way to do it from the architectural POV
inky_ has joined #maemo-leste
<freemangordon>
having some code here and some code there is not the best option imo
<Wizzup>
I think hidden ap stuff is not a driver for it
<freemangordon>
but, hidden wlan + reg domain?
<Wizzup>
I don't object to another daemon, I said 'whatever we decide manages ofono state'
<Wizzup>
It sounds like a solution in search of a problem, and I'd rather look at the problem and then see if it is the most sane solution
<freemangordon>
no, this should not manage ofono, it just needs to register to ofono and set reg domain on cell registration
<Wizzup>
It is absolutely true that wpa_supplicant doesn't do 'mobile things' that we want, but we need to figure out where that fits
<freemangordon>
someone shall do that
<Wizzup>
e.g. setting lower power mode is something libicd-network-wpasupplicant can just do
<Wizzup>
and it could also set the region based on ofono info even
<bencoh>
silly question, but why wpasupplicant? is it because it's one of the few (only?) maintained project with decent support?
<bencoh>
(I haven't checked)
<Wizzup>
bencoh: as opposed to Intel Wireless Daemon?
<bencoh>
I honestly don't know what would be the alternative, so it's an open question
<Wizzup>
afaik almost everything uses wpa_supplicant on linux
<Wizzup>
networkmanager uses either wpa_supplicant or iwd
<bencoh>
and maemo5 uses somme custom/outdated implementation, right?
<Wizzup>
freemangordon: I'm fine chatting about any solution in any case, and if that is (yet) another daemon then that's fine, but I think it makes sense to take some of the other ofono/modem parts into consideration there as well
<Wizzup>
freemangordon: it really would not be much work to have libicd-network-wpasupplicant read ofono modem country and change wireless region based on it probably
<Wizzup>
does it make sense? don't know
<bencoh>
how others do it?
<bencoh>
I mean ... companies sell phones / wireless products; how do they do it?
<Wizzup>
wpa_supplicant with networkmanager probably
<bencoh>
do they wait for user input before enabling certain channels?
<Wizzup>
oh, that
<bencoh>
yeah
<uvos>
they mostly dont care really
<Wizzup>
I doubt any UX bothers people with that
<bencoh>
hmmm, unlikely
<Wizzup>
no user wants to be bothered by this info I think
<Wizzup>
'just do it'
<bencoh>
no I meant, companies selling product to the public
<uvos>
lots of android phones i bought will happly connect to wrong channel at least
<uvos>
i think they might do passive scann
<uvos>
a wlan client really dosent need to care about the allowed channels anyhow
<uvos>
it can just passive scann those
<bencoh>
oh and ... iirc there is a "default"/blank contry that only allows a minimum set
<uvos>
and only start tx if it gets beacons
<bencoh>
uvos: in practice, active scan is usually enabled by default
<Wizzup>
I believe that is true @ active scan
<bencoh>
and some drivers/chips don't even have proper passive scan support
<bencoh>
(ie there is no way to disable active scan on some drivers)
<uvos>
right
<uvos>
what im saying is that i think andorid might passive scann channells not in the worldwide or current domain
<uvos>
and then still connect if it gets beacons
<uvos>
at least it seams to work with my device and hostapd
<uvos>
desktop linux distros seam to not care mostly
<uvos>
and just ship the subset
<uvos>
at least thats whats happing on the debian and arch systems on my desk
_inky has joined #maemo-leste
inky_ has quit [Read error: Connection reset by peer]
jmlich has joined #maemo-leste
<freemangordon>
sorry, guys, I don;t get it - I think we shall adhere to regulations/rules, no matter what android do
<freemangordon>
also, debian is server distro, not phone
<freemangordon>
so not really the correct example
<freemangordon>
and BTW, if by "android phone" you mean chinese ones, lets not take them as example
jmlich has quit [Client Quit]
inky has joined #maemo-leste
<uvos>
its a xt1602 and i doubt it violates anything
<uvos>
its probubly just passive scanning as i say
<freemangordon>
could be
<uvos>
and im not saying to emulate any of these
<uvos>
im simply stating what others do
<freemangordon>
ok
<uvos>
as bencoh asked
jmlich has joined #maemo-leste
<freemangordon>
BTW, I think we can only actively scan for hidden wlan
<freemangordon>
if I read the docs correctly
jmlich has quit [Client Quit]
jmlich_ has joined #maemo-leste
jmlich_ is now known as jmlich
<Wizzup>
freemangordon: yes, we do
inky has quit [Ping timeout: 268 seconds]
_whitelogger has joined #maemo-leste
mp1075 has joined #maemo-leste
mp107 has quit [Read error: Connection reset by peer]
mardy has quit [Ping timeout: 268 seconds]
mp1075 is now known as mp107
mardy_2nd has joined #maemo-leste
dos1 has joined #maemo-leste
dos has quit [Ping timeout: 268 seconds]
dos1 is now known as dos
pagurus has quit [Ping timeout: 268 seconds]
inky has joined #maemo-leste
Evil_Bob has quit [*.net *.split]
diejuse has quit [Quit: Leaving.]
Evil_Bob has joined #maemo-leste
inky has quit [Ping timeout: 272 seconds]
inky has joined #maemo-leste
inky has quit [Ping timeout: 264 seconds]
diejuse has joined #maemo-leste
inky_ has joined #maemo-leste
_inky has quit [Ping timeout: 244 seconds]
jmlich has quit [Remote host closed the connection]
<Danct12>
zram has always been enabled by default on leste since i installed it
<Danct12>
what i have on it now is mostly just dillo and hexchat
<Danct12>
dillo works pretty great on the n900, it's one of the browser that is modern enough to load https websites
<bencoh>
:)
<sicelo>
Debian 10? systemd?
diejuse has quit [Ping timeout: 265 seconds]
inky has joined #maemo-leste
<Daanct12>
Its leste, devuan.
<sicelo>
Ok
<Daanct12>
Also it doesnt have systemd
<sicelo>
:-) thought devuan would have its own OS name
<Daanct12>
It does, at least thats what neofetch told me
<Daanct12>
Also os-release
<Daanct12>
Not sure why HexChat doesnt pick it up
inky has quit [Ping timeout: 264 seconds]
inky has joined #maemo-leste
_inky has joined #maemo-leste
Daanct12 has quit [Ping timeout: 264 seconds]
inky has quit [Ping timeout: 264 seconds]
inky_ has quit [Ping timeout: 272 seconds]
inky has joined #maemo-leste
Danct12 has quit [Ping timeout: 268 seconds]
diejuse has joined #maemo-leste
pagurus has joined #maemo-leste
cockroach has joined #maemo-leste
cockroach has quit [Quit: leaving]
mardy_2nd has quit [Quit: WeeChat 2.8]
cockroach has joined #maemo-leste
belcher_ is now known as belcher
<Wizzup>
uvos: the droid 3 indeed has a nice casing
inky has quit [Ping timeout: 264 seconds]
<uvos>
Wizzup: yeah its the old motorola build quality, they really cheepend the cases right before they went under.
<uvos>
the d4 is just.... bad
<Wizzup>
yeah, it doesn't feel quite as sturdy
<uvos>
i gues the fact that so many still seam to work (even quite beat up ones) vindicates it a bit
<buZz>
will d3 get targeted aswell? :)
<uvos>
buZz: maybe if Wizzup dose the work. it might just work if you just change the ram addresses as like bionic is the same display and same hardware otehrwise
<uvos>
so might just boot
<buZz>
oh wow
<uvos>
d3 ist just d4 with less ram no lte and a metal case
<uvos>
other wise its the same device
<uvos>
Wizzup: D3 is Solana btw if you want to check moto sources for ram map
<Wizzup>
uvos: Solana?
<Wizzup>
uvos: we might need modified kexecboot and such as well, no?
<uvos>
d3's code name
<Wizzup>
right
<Wizzup>
first thing I did was externally charge the battery so that it boots
<uvos>
in source d4 = masarati d3 = solana
<uvos>
Wizzup: sure
<Wizzup>
it'd be fun to make it all work, but I'd need hand holding
<uvos>
id start with safestrap
<uvos>
and get something to boot there
<Wizzup>
it's booted to android atm
<Wizzup>
ok
<uvos>
id guess that d3 has the cpcap setup of bionic
<uvos>
just becuase its closer to that than d4 dates wise
<Wizzup>
uvos: I remember now also that someone bought a phone like the droid 4 and it accidentily booted with our d4 image
<Wizzup>
not sure if that was bionic or something else
<Wizzup>
iirc it was something else
<uvos>
Wizzup: that was a bionic
<uvos>
thats how we came to support this device
<Wizzup>
ok
<Wizzup>
:p
inky has joined #maemo-leste
<uvos>
lucky for him and us that was before tmlind implmented setting up the cpcap regs in the mainline kernel so bionic just worked with d4 dts at that time on the bootloader setup.
<Wizzup>
right
<Wizzup>
As you saw, I made a ticket for supporting it
<uvos>
no utags :(
<Wizzup>
mhm
<uvos>
solana cdt.bin shows that mbm dosent use utags on this device