<parazyd>
freemangordon: Managed to move connui stuff to stable last night
<parazyd>
Moved everything that made sense btw, and will review and update metapackages today.
<parazyd>
uvos: So we're fine with enabling charge-mode, and fbkeyboard?
<freemangordon>
parazyd: thanks!
<parazyd>
:)
doc has joined #maemo-leste
pere has quit [Ping timeout: 240 seconds]
pere has joined #maemo-leste
sunshavi has quit [Remote host closed the connection]
diejuse has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
parazyd: yes, fbkeyboard should be activated allready on devel (on bionic only as intended)
<uvos>
Daanct12: no every thing is missing software side the f7 f8 thing is a n900 odity we should probubly change
<uvos>
parazyd: did you read my complaints about irc-this-week btw
<freemangordon>
uvos: why it should change? f7/f8 are not volume keys as one may think, those are multipurpose, context specific keys
<uvos>
freemangordon: they are volume keys, there use elsewhere nonwithstanding. every single other device calls them volume, android vendor kernels call them volume. if we change n900 to fit everything else we save us a lot of headache
<freemangordon>
and then we will have the headache to fix all the code that uses f7/f8, just because android! calls them volume. Good reasoning...
<uvos>
no it goes mucht deper than android
<uvos>
the mainline kernel calls these volume, they are volume on x86
<uvos>
etc
<uvos>
if you run leste on some random x86 device you want volume to change with the volume buttons on keyboard etc
<freemangordon>
pc 105 keyboard doesn't have volume buttons lst time I chacked
<freemangordon>
*last
<uvos>
yeah the standart ibm layout might not have them but manny manny manny pc keybaords have volume keys
<uvos>
thats what XF86Volume* was added for
<uvos>
f7/f8 is silly nokia Stupidity
<buZz>
XF86AudioRaiseVolume XF86AudioLowerVolume
<freemangordon>
sure, but again, what you call "volume keys" is used for multiple purposes on maemo
<buZz>
those i guess?
<uvos>
freemangordon: so? there primary purpose is volume, they make the moste sense as volume, the camer app zooming or osso-xterm changing font dosent change that
<freemangordon>
no, there is no primary purpose, please get out of your android-ish way of thinking
<parazyd>
uvos: Regarding irc-this-week, you want me to escape that ^A I guess?
<freemangordon>
they are used in xterm(to change the font size) book readiers use them to turn pages, etc,etc
<uvos>
parazyd: yeah i guess, just whatever is nessecary so that file and firefox etc detect the file as plain text
<parazyd>
uvos: okay
<parazyd>
Will do that sometime today
<uvos>
thanks ;)
<parazyd>
I'll clean the file now
<parazyd>
Fix code after I eat something :D
<uvos>
freemangordon: so? the thing is that if you want to enforce your these 2 keys are f7/f8 you will have to change the dts on every device ever just to fit the n900 mold. and users will complain volume odosent change with pc volume keys
<uvos>
that is silly
<buZz>
cant xterm just use XF86AudioRaiseVolume etc?
<uvos>
of course
<uvos>
thats what i am proposing
<uvos>
Wizzup: parazyd ^^^ please comment on this dissagreement....
<buZz>
and eh, couldnt we just have them -also- be f7/f8 ?
diejuse has quit [Quit: Leaving.]
<uvos>
if you dont want to change n900 dts sure
<parazyd>
Aren't Droid4/Bionic and Pinephone doing these as XF86Audio*Volume already?
<freemangordon>
XF86 keys are *already* supported in the relevant parts
<uvos>
but its just a a 4 byre change
<uvos>
parazyd: yes ofc
<buZz>
i think freeman is mostly thinking about all the maemo apps that exist already?
<freemangordon>
yes
<uvos>
parazyd: every pmos device and every android device etc
<parazyd>
So the existing maemo apps work only on N900
<uvos>
yes
<freemangordon>
vendor kernels is not something we ever wanted to support
<parazyd>
That's funny
<uvos>
freemangordon: its not vendor kernels
<freemangordon>
but what?
<uvos>
freemangordon: its all the mainline kernels for devices
<parazyd>
freemangordon: Mainline
<uvos>
its just what everyone decided these buttons are
<uvos>
and it makes sense users call these "volume buttons" too
<uvos>
WE call them volume buttons in discussions even
<freemangordon>
I understand that argument, but the question is - how you're going to make difference between volume buttons on your hands free and the ones on the device, to not turn page of the book reader you're currently using?
<freemangordon>
I don't want my hands free device to change font size in xterm either
<freemangordon>
the same goes for those fancy multi-media kbds with audio buttons on them
diejuse has joined #maemo-leste
<freemangordon>
Nokia did it that way not because they were stupid, but because they were smart
<uvos>
so for muti-media keyboards i think zooming makes sense. as for hands free, interesting question i wonder how android dose this.
<buZz>
i dont understand the controversy really, doesnt your external keyboard have f7/f8 too?
<uvos>
buZz: sure but other devices dont
<uvos>
and f7/8 is bad ux if volup voldown dosent also work
<buZz>
other devices than keyboards?
<uvos>
yeah like phones
<freemangordon>
buZz: keys on your phone are kbd as well
<buZz>
right
<freemangordon>
the conversation is about hwt keycode shall volume keys generate
<buZz>
so you are saying you want to keep em as f7f8 because you hookup a keyboard to your phone often?
<freemangordon>
*what
<uvos>
no
<uvos>
so n900 dose f7/f8
<freemangordon>
no, because I hook handsfree often
<uvos>
but every other device dose volup vol down
<uvos>
so you need to reconcile this somehow
<freemangordon>
"every device" is not really an argument, n900 is the best amongst all of them, both HW and SW wise.
<freemangordon>
and please dont bring the number of cores to the table
<uvos>
erm... ok
<uvos>
i hate the keyboard
<uvos>
its too small and close to the display :P
<freemangordon>
then leste is not for you
<buZz>
i find it too small and too thick
<freemangordon>
ah. on n900
<freemangordon>
well, it was good enough for me 10 years ago...
<freemangordon>
now... I need good light :)
<uvos>
1000 years ago a slave carrying a letter was good enough
<uvos>
thats hardly a argument
<freemangordon>
the fact that something is newer doesn;t make it any better either
<uvos>
no but thats beside the point
<uvos>
the point is we want leste to just work
<uvos>
on a wide veriaty of devices
<freemangordon>
neither the fact that "everybody does it, but you"
<buZz>
on as many devices as possible, right?
<uvos>
and the f7/f8 thing is an impedement
<uvos>
"everybody does it, but you" is an argument in foss
<uvos>
becaue it fosters interoperability
<freemangordon>
uvos: sure, but that should not be on the price of bad UX
<freemangordon>
and BT controlling bookreader is a bad UX in every book I have around
<freemangordon>
BT HF that is
<uvos>
idk if it is really
<uvos>
so the vol keys inline on a wired headset
<freemangordon>
sure it is, this is real multitaskyng OS
<parazyd>
uvos: Fixed, but I had to reset irc-this-week.txt so it starts from now. The main irc.txt is ok of course.
<uvos>
i think are great if they would do this
<uvos>
parazyd: thanks
<parazyd>
yw
<freemangordon>
so you may have xterm or bookreader or whatever opened while you have a phone conversation
<freemangordon>
you want BT HF volume keys to change the audio volume, not to turn pages
<uvos>
freemangordon: in this case the vol keys on device not chaning the call volume is bad ux.....
<uvos>
in all cases
<uvos>
so you would need some kind of global lock
<freemangordon>
uvos: they do while you;re in a call, IIUC
<uvos>
which is easy to accive via xgrabkey..
<uvos>
freemangordon: right
<freemangordon>
lets not reinvent the wheel, ok?
<uvos>
freemangordon: im sure thats how it works currently
<uvos>
freemangordon: it needs to block f7/f8 this way
<parazyd>
freemangordon: Keep in mind no device except the N900 does this f7/f8 thing
<buZz>
maybe n810 etc aswell?
<parazyd>
buZz: We don't have an n810 image nor support
<parazyd>
uvos: Will you have some time in the afternoon to give me a second pair of eyes on metapackages and perhaps leste-config?
<uvos>
parazyd: sure
<parazyd>
Cool
diejuse has quit [Quit: Leaving.]
diejuse has joined #maemo-leste
diejuse has quit [Quit: Leaving.]
* sicelo
keeps wondering if he shouldn't quit Leste because it's based on silly s/w
<Wizzup>
freemangordon: the f7/f8 handling is not too hard I think
<parazyd>
?
<Wizzup>
freemangordon: also many oher devices uses other keys than f7/f8 already
<bencoh>
sicelo: wait, what?
<uvos>
its a dig at me
<uvos>
dont mind it
<Wizzup>
parazyd: I do have a n810 btw, but no support
<Wizzup>
I do think the F7/F8 is quite random
<Wizzup>
but don't necessarily have a good solution
<Wizzup>
there are F keys until F20
<Wizzup>
even more actually it seems
<uvos>
some of those dont work
<Wizzup>
linux/keyboard.h has until K_F245
<uvos>
any keycode >240 something is impossible to use with x
diejuse has joined #maemo-leste
uvos has quit [Quit: Konversation terminated!]
<Wizzup>
right
diejuse has quit [Client Quit]
diejuse has joined #maemo-leste
<freemangordon>
Wizzup: could you elaborate on the "fix", I am not quite sure I understand
<Wizzup>
freemangordon: I wrote that while reading backlog, the way I see it F7 and F8 are a bit arbitrary, and whatever we do, we need to at least sync the keys with other devices that we support - droid4 has the same buttons: power and volume -/+, and we need to figure out how to handle them properly
<Wizzup>
F7/F8 feel arbitrary to me (why not F9/F10? etc), and xf86 volume keys might also not be ok
diejuse has quit [Client Quit]
<Wizzup>
I suppose they are keys that serve different functions in different contexts
<Wizzup>
I am trying to think of equivalent stuff on PC keyboard layouts but don't quite know
<parazyd>
Well there's the Fn key in hardware, but I think that's not a valid thing on phones
<parazyd>
At the very least it's two keypresses and saving state
<Wizzup>
I don't mean it in that way per se
<Wizzup>
That's just about how a key is sent to the os, but I mean I am not sure what key would make (more) sense
<Wizzup>
brb
<parazyd>
ok
<parazyd>
I need to finish up the metapackages for stable now
<parazyd>
Could discuss more later
peetah has quit [Quit: -]
<parazyd>
Wizzup, uvos: We also have some libsdl1.2 in -devel. Should I promote it?
<parazyd>
note-to-self: Check why alpha/beta themes try to pull in devel theme
<Wizzup>
I am pretty sure we can do all of that, someone just needs to do it *and* make sure we can flash a certain u-boot version safely without messing wiht existing setups
<parazyd>
Yeah ok
<sicelo>
fremantle u-boit DOES support cmdline
<parazyd>
I already talked to Pali about this
<Wizzup>
sicelo: having both leste and fremantle generate u-boot menu using their own scripts is recipe for disaster though
<parazyd>
sicelo: Right, but thing is our n9xx-linux has hardcoded cmdline
<parazyd>
Yeah that's my point. We can then easily maintain Leste-specific boot.scr
<Wizzup>
yup
<Pali>
yes!
<Pali>
"run sdboot" tries to run boot.scr script from uSD
<parazyd>
Fantastic
<Pali>
and "run sdboot" is called by "External SD card" menu entry
<Wizzup>
parazyd: that is not the default btw
<Pali>
this menu entry is by default present if you do not have your own bootmenu.scr in eMMC
<Wizzup>
and it is only run upon user action
<Wizzup>
parazyd: does it also read from sd card?
<Wizzup>
err
<Wizzup>
Pali: ^
<Wizzup>
when preparing the menu
<Pali>
uSD is not default boot option
peetah has joined #maemo-leste
<Pali>
default is attached kernel without cmdline
<Pali>
but bootmenu.scr in eMMC can specify custom default entry
<parazyd>
This still needs user interaction
<parazyd>
To change
<Wizzup>
Pali: the way I see it: (1) OS on eMMC and OS on uSD should both ideally be able to provide entries for the menu, and maybe even determine what should be default with some priority
<Wizzup>
and leste, I think, currently typically is on uSD and fremantle on emmc for most
<Wizzup>
so this way leste would have to override emmc on fremantle to get its values in, right?
<parazyd>
Wizzup: We would also use mainline u-boot and keep it up to date with apt
<parazyd>
Wizzup: This way we can also control the emmc script
<Pali>
well, you can overwrite u-boot source file include/configs/nokia_rx51.h to loads bootmenu.scr from uSD instead of eMMC
<uvos>
parazyd: parazyd: so charge mode should work everywhere, i tested it on d4, bionic and on the n900 by switching to the runlevel after boot
<parazyd>
I tested on d4/bionic only
<parazyd>
Updating my N900 now and will try too
<uvos>
ok someone should test it on pp
<uvos>
but thats what devel is for no? :P
<parazyd>
:)
<uvos>
parazyd: the only blemish being that currently /sys/class/power_supply/battery/status on mapphones just reflects current_now
<Pali>
is there any issue if u-boot always tries to load bootmenu.scr from uSD and if it fails then tries to load it from eMMC and if it fails then fallback to defalt?
<uvos>
so sometimes the device will fail to enter charge-mode becuase the device is using to mutch current at that moment
<uvos>
but thats just a mapphone kernel problem
<parazyd>
uvos: fail in what sense?
<uvos>
fail in the sense that it boots to hildon instead
<parazyd>
Unless there was something else you wanna add
<parazyd>
Alright
<uvos>
no
<parazyd>
Will build this in a little bit
<uvos>
for hildon meta it might make sense to only have fbkeybord in bionic
<uvos>
since you cant reach it elsewhere atm
<uvos>
but it dosent hurt to have it installed either
<parazyd>
ah but you asked me to add it to all of the non-keyboard devices :p
<sicelo>
Pali: I tried to boot Fremantle with upstream u-boot once (with kp image), but it didn't boot. Is this expected, or I made a mistake somewhere?
<parazyd>
imho it's fine if installed
<uvos>
right and you said we can figure out how to enter the runlevel later
<uvos>
im just saying its dead weight atm
<uvos>
but its fine
<Pali>
sicelo: it should work
<sicelo>
I'll try again and report back
<Pali>
if it does not work then something is broken and needs debugging...
<freemangordon>
Wizzup: kinda agree, but those new key should be really way more sane than F7/F8 to worth the effort of porting all the code to them.
<sicelo>
Okay. I'll test. The idea is to flash upstream u-boot (which Leste would prefer afaict), but still be able to boot Fremantle (what I prefer)
<parazyd>
dreamer, freemangordon, buZz, uvos, Wizzup, sicelo, etc.: Do you think it's a good idea to have another channel, say ##lestians (or propose another name), for non-dev Leste discussions?
<uvos>
parazyd: we did this before
<uvos>
parazyd: it dident work out mutch
<parazyd>
mhm
<sicelo>
I don't think it's good idea
<parazyd>
Asking because someone on Twitter asked.
<Wizzup>
freemangordon: yeah, I suppose so, I don't know how many handle the key, I guess web browser and some other apps. Something else to keep in mind is that some applications automatically handle zoom keys already, I think (I have to test), like pdf or image viewer, or browser, from debian, so keeping that kind of compat in mind when picking one might make sense (this likely won't be volume key ;-))
<freemangordon>
Pali: do you want me to do anything else for u-boot?
<Pali>
I do not know if tom wants that your patch to be sent in git-format-patch
<freemangordon>
I bet he does
<freemangordon>
but as you know, I prefer to leave the paperwork to you :p
peetah has joined #maemo-leste
diejuse has quit [Quit: Leaving.]
<Pali>
so for now just need to wait for tom answer
<Wizzup>
probably no reason to wait, can just send a rfc patch, right?
diejuse has joined #maemo-leste
<parazyd>
Pali: mmc patch LGTM
<parazyd>
Pali: setenv mmctype ext4
<parazyd>
Does this imply the partition has to be ext4?
<Pali>
ext4 means to read ext2/3/4 fs
<parazyd>
ok, and fat is fat
<parazyd>
ok
<parazyd>
Good
<freemangordon>
Pali: Wizzup: yes, no reason to wait, the answer we are waiting for is -mthumb related, not DM_USB
<Pali>
older u-boot version had separate ext2/3 and ext4 implementations, new u-boot has one unviersal ext2/3/4 implementation with just ext4load command, hence ext4 mmctype
diejuse has quit [Read error: Connection reset by peer]
<Wizzup>
ah, like mainline
<Wizzup>
parazyd: well keep in mind we'll have to be able to install u-boot first via leste, and we need to figure out ow to do it without breaking all the differnet setups
<Wizzup>
like, someone can have no u-boot on their device, and have fremantle kernel there, and boot leste via 0xFFFF
<parazyd>
Wizzup: Yeah as I said, already discussed this with Pali. There are helpful scripts.
<Wizzup>
in that case we do *not* want to flash u-boot
<Wizzup>
we'd break fremantle
<Pali>
you can extract current kernel from nand, append it into prepared u-boot binary and then flash this u-boot binary
<Pali>
(with appended kernel)
<Wizzup>
yeah, but can we decide to do that on our own?
<parazyd>
Wizzup: In any case, I'd prefer if we use mainline u-boot for Leste.
<freemangordon>
why not?
<Wizzup>
freemangordon: if you booted a livedistro, would you expect it to modify your grub config without asking you?
<Pali>
by default U-Boot boots attached (=fremantle) kernel
<freemangordon>
if there is a big fat warning
<Wizzup>
freemangordon: yes, that is what I am saying
<freemangordon>
ah, ok :)
<Pali>
and if you provide bootmenu.scr to eMMC you can overwrite default boot menu entry
<Wizzup>
I think the package should be avail in repos, but not in any meta, and we can juts have it be present on images we make, or something
<Wizzup>
well, no, that won't work still
<Pali>
and after above patch you can put bootmenu.scr also into uSD
diejuse has joined #maemo-leste
<parazyd>
All promoted to stable
<parazyd>
Let me know if you experience issues upgrading
inky has joined #maemo-leste
lea_ has joined #maemo-leste
lea_ has quit [Client Quit]
<uvos>
parazyd: btw with the charging-mode change you might want to conisder moving droid4-battery-calibration to sysint
<parazyd>
ah indeed
<uvos>
so there is a chance charging-mode ends up with a callibrated battery
<parazyd>
Made a note
<parazyd>
Doing N900 upgrade now
<parazyd>
Wizzup: * Caching service dependencies ... [ ok ]
<freemangordon>
"E: Unable to locate package tootle"
<freemangordon>
Wizzup: it is in bullseye too
<meldrian>
Once the new battery is delivered i'll try to ressurect the n900 for home use with meamo leste. Just want to check if fediverse is one of its borders. Iam reliefed its not.
<freemangordon>
actually this particular client is not available in leste
<freemangordon>
because it is based on current debian stable
<freemangordon>
but maybe it will just compile, who knows
<meldrian>
It doesn't need to be tootle. Every client with basic functionality will do it.
<bencoh>
considering the deps, it might compile easily
<Wizzup>
it might even just dpkg -i
<freemangordon>
meldrian: whatever is available in debian stable, is available in leste as well
<bencoh>
Wizzup: doesn't sound great ABI-wise, but dpkg-buildpackage should be fine
<freemangordon>
:nod:
<meldrian>
... and that's a lot. Can't wait to begin testing.
diejuse has joined #maemo-leste
<freemangordon>
Pali: yay, seems WDT patch has been merged into -next :)