<suppboi>
what package includes gles_CM.h? i been tryna find it but it breaks other dependencies. i do have the libs though. somehow they come pre installed or something
<suppboi>
im trying to build openarena
<suppboi>
libgles1-sgx-omap4-cant be found either and its clearly therep
<sicelo>
I'm not sure we want unbound on the phone. Extra daemon likely means more battery draw
suppboi has joined #maemo-leste
<suppboi>
hi
<suppboi>
what it do
<suppboi>
pimps
<suppboi>
Wizzup: what do i need to build for droid 4 kernel?
<suppboi>
dtbs and zimage?
<tmlind>
i got a gps fix pretty fast yesterday within a few minutes while outside with the MPDTIME patch, this was after uploading data with droid4-agps
<tmlind>
so the MPDTIME seems to be done, i think the only mystery remaining is what the first parameter for MFSOPEN might be
<tmlind>
it could be the first MFSOPEN parameter does not matter, and droid4-agps is just using AT+MFSOPEN=1234567890,"xtra2.bin"
mardy has joined #maemo-leste
<tmlind>
here are some MFSOPEN examples if anybody has any ideas:
<tmlind>
0113AT+MFSOPEN=1,"xtra2.bin"
<tmlind>
0651AT+MFSOPEN=2352706887,"xtra2.bin"
<tmlind>
0738AT+MFSOPEN=4041702676,"xtra2.bin"
<tmlind>
0870AT+MFSOPEN=759692495,"xtra2.bin"
<tmlind>
the number does not change for the following xtra2.bin uploads
<freemangordon>
how big is that file?
<freemangordon>
tmlind: ^^^
<tmlind>
freemangordon: it's tiny, android uses the shorter version with few days of data, droid4-agps uses i think six days of data
<freemangordon>
this is almanac?
<tmlind>
yup
<freemangordon>
ah
<tmlind>
so the longer version is about 26530 bytes
<tmlind>
does not seem to be a crc or anything :)
<freemangordon>
why not?
<freemangordon>
checksum?
<tmlind>
could be, but see the value of 1 above :)
<freemangordon>
yeah
<tmlind>
timestamp or message number based something?
<freemangordon>
I was thinking about timestamp, but I doubt it is
<freemangordon>
good puzzle, but I need more data, like, a couple of files
<freemangordon>
not now though
<freemangordon>
I am on h-i-m
<tmlind>
yeah i have some logs captured from los 14.1
<tmlind>
why would open take some param that does not seem to be used later on at all?
<freemangordon>
does not make sense
<tmlind>
open returns a fd anyways, typically 0
<freemangordon>
maybe this is some "user data" to be returned later on
<tmlind>
yeah
<tmlind>
there's some src related unused command also
<freemangordon>
do you see any of those 3 values later on in communication stream?
<freemangordon>
ignoring '1' ofc
<tmlind>
no just the fd gets used for writes and close
<freemangordon>
weird
<tmlind>
so there's also AT+MFSCRC, but i'm not seeing it in any logs
<freemangordon>
afaik we can;t have crc of 1
<freemangordon>
or can we?
<tmlind>
no i don't think so :)
<tmlind>
here are the related commands where we have the mystery number as 1 for example:
<freemangordon>
Wizzup: I don;t think this is acceptable
<freemangordon>
tmlind: can't we just feed IDA with the $binary in question and try to guess what it does?
<tmlind>
i guess yeah
<freemangordon>
if you give me the binary and provide some hints which functions I shall look in, I will do it
xmn has quit [Ping timeout: 250 seconds]
rafael2k has quit [Ping timeout: 256 seconds]
macros__ has joined #maemo-leste
inky_ has quit [Ping timeout: 256 seconds]
_inky has quit [Ping timeout: 256 seconds]
inky_ has joined #maemo-leste
_inky has joined #maemo-leste
<Wizzup>
freemangordon: so imho I don't think it's ok to talk this way about uvos' work, and I probably merged it, he made a PR for it, and I didn't notice the regression
<Wizzup>
the ability to type into raw x windows imho is very appreciated
<Wizzup>
There are many shortcomings in him that we need to tackle and it currently _only_ working in a gtk2 window is a big one
<Wizzup>
with that commit it not only works in every x window, but the ability to raise it forcefully also adresses a lot of use cases with devices without keyboard
<Wizzup>
sure, we should fix bugs if they get introduced, but the direction itself I think is a good one
<Wizzup>
suppboi: I'm too late to answer it seems, but if you're trying to upgrade, use dist-upgrade
<Wizzup>
freemangordon: in any case I think any upsetness here should be directed at me not uvos, although I think we discussed the PR
<Wizzup>
freemangordon: why is it not acceptable?
<tmlind>
freemangordon is always upset if something behaves different from fremantle, no matter how sucky it behaves in fremantle :)
amk has quit [Ping timeout: 256 seconds]
amk has joined #maemo-leste
<Wizzup>
yeah ok but in this case it should be directed at me :)
<Wizzup>
it looks like we probably should have kept the for each plugin function
<tmlind>
huh.. so if d4 slide is closed or lcd disabled or something like that, my d4 sees gnss satellites indoors
<tmlind>
theory so far is that d4 won't get a fix for a long time unless lcd is blanked or slide closed :)
<MartijnBraam[m]>
the most important part of fosdem :P
<Evil_Bob>
:D
inky has joined #maemo-leste
inky has quit [Remote host closed the connection]
_inky has quit [Ping timeout: 256 seconds]
inky_ has quit [Ping timeout: 240 seconds]
inky has joined #maemo-leste
<freemangordon>
tmlind: well, in this particular case, it is not that it behaves differently, it simply does not behave as the code to call HIM plugins was simply removed :) . Unless we extend the definition of "behaves different".
<freemangordon>
Wizzup: to me this commit shall be reverted and redone, as obviously it does way more than what is said in the commit description
<Wizzup>
is this the one that breaks special keys keyboard?
<freemangordon>
ot to say that the changes shall be split in at least 3 commits (plugin code removal, dbus stuff and support for input into plain x)
<Wizzup>
right
<Wizzup>
I think if we know this is the one that breaks it, we can ask uvos to see if he can fix it
<freemangordon>
I would prefer to have a discussion on why all the changes
<freemangordon>
because mre stuff is removed
<freemangordon>
*more
<Wizzup>
ok, and checking out to before that commit makes svc work?
<Wizzup>
_totally_ unrelated but I was thinking about a uinput backend for a input method, just emulate an actual keyboard, could be quite generic too
<freemangordon>
didn;t try, but it is obvious that there is no way for any plugin to work without its code being called
<freemangordon>
and the removed code calls hildon_im_plugin_key_event(), so plugins to have a chance to react
<Wizzup>
seems very likely that this is the problem then yeah
<Wizzup>
well let's wait a bit, uvos is usually not around much on weekends
<freemangordon>
so, this is why keyboard layout switch and svc (and prediction and whatnot) does not work
<freemangordon>
basically it is like we have no plugins now
<Wizzup>
right it looks likt the message filter stuff is gone
<freemangordon>
mhm
<Wizzup>
yeah it's not clear why this is necessary to make the xlib stuff work
<Wizzup>
I could try to work on this today, but I'm ok waiting for a bit too
<freemangordon>
no, lets wait for uvos, he should know/remember why did he removed that
<freemangordon>
also, dbus stuff is in no way related to the commit $subject
<Wizzup>
I think the dbus part is required to summon it externally
<Wizzup>
but yes it could be split out
<Wizzup>
freemangordon: like on the bionic/d4 we have a button to summon vkb
<freemangordon>
I know why it is needed and agree
<Wizzup>
ok
<freemangordon>
the poin tis that this change belongs to a separate commit
_uvos_ has joined #maemo-leste
<freemangordon>
_uvos_: Hi! First of all apologize if you feel offended by my "WTF" comment, it was not mean to offend you, but Wizzup said it is offensive :)
<freemangordon>
on the matter - do you have any clue why you removed plugin code back then?
<_uvos_>
yes, i know this function is needed, i missread it and thought its one and only call was in the if statement that deals on raisng the vkb on enter which was removed in favor of the new dbus call, as this method was ver broken (it forced the redirect though him causing key order races and the translation of the hwkbd keys to send the code kp_enter breaking lots of applications that listen to enter only)
<_uvos_>
as i have mentioned many times i know this was a mistake and i corrected it in the commit i linkede to manny times now
<_uvos_>
this commit dosent restore the function per say (as it was used only one) but re adds code to the same effect
<Wizzup>
_uvos_: I think perhaps more is necessary
<freemangordon>
I would think of doing a reset and history rewrite
<_uvos_>
i dont think so, but i cant read any code rn
<freemangordon>
it will become a mess
<freemangordon>
like: revert to befor the offending commit
<Wizzup>
not ideal to rewrite git history
<freemangordon>
I know
<Wizzup>
I can try to break up the patch into several ones a bit later, but if we can just restore the behaviour with a new patch I think that is easier
_uvos_ has quit [Quit: _uvos_]
<freemangordon>
Wizzup: no, we won;t be able to assess the patch
<Wizzup>
can you elaborate?
<freemangordon>
it is very hard(to me at least) to review the combo of old patch and that new one
<freemangordon>
so, if you are against history rewrite, ok
joerg is now known as DocScrutinizer
<freemangordon>
but then we'll have to revert the offendin patch and the one after it
<freemangordon>
as it depends on it
<freemangordon>
and then create a new ones
<freemangordon>
are you ok with that?
<freemangordon>
Wizzup: ^^^?
<freemangordon>
so, we should have this split in 3:
<freemangordon>
2. KP_ENTER related code removal
<freemangordon>
1. dbus code
<freemangordon>
3. support for input into plain x
<Wizzup>
I mean, yeah, I can live with that
<freemangordon>
ah, I don;t insist on rewriting, was just a suggestion to no create a mess
<freemangordon>
without the rewrite, we will do 2 reverts and 3 more patches
<freemangordon>
I will do that and will make a PR so uvos to be able to review when he has a chance
<freemangordon>
ok?
avoidr has quit [Ping timeout: 250 seconds]
<Wizzup>
sure, sounds good to me
<Wizzup>
I assume you will re-add the x11 backend unicode stuff and shift logic after that?
<freemangordon>
yes
_inky has joined #maemo-leste
avoidr has joined #maemo-leste
<Wizzup>
brb
xes has quit [Quit: WeeChat 3.4]
xes has joined #maemo-leste
_uvos_ has joined #maemo-leste
<_uvos_>
i am not sure why it is nessecary to revert and then wirte the same thing again
<_uvos_>
rather than just merging the fix
<_uvos_>
its not like you cant git diff the whole series
<_uvos_>
to review it
_uvos_ has quit [Client Quit]
<freemangordon>
because it will be easier for everybody to review
<freemangordon>
I will also split into 3 commits
<freemangordon>
Wizzup: uvos: how to test the "plain x" part? I need dbus patch first, correct?
_uvos_ has joined #maemo-leste
<_uvos_>
i dont think you can splitt it and have it be bisectable the enter handling and the x11 input shares a commit becuase enter in vkb breaks if you do one chane but not the other
<freemangordon>
dbus part should not depend on x part, no?
<_uvos_>
it might work now because i also removed it in framework
<_uvos_>
yes it dose
<_uvos_>
its broken without the enter unredirection
<_uvos_>
becaus him will send itself enter
_uvos_ has quit [Client Quit]
<freemangordon>
ok, but if I create a 'dbus' patch first, then remove "enter" part and then do "x" part, it should be bisectable
<sicelo>
meanwhile, some pmos hackers are trying to make N900's Angry Birds to work in pmos :-)
<freemangordon>
hehe
<sicelo>
if you had a few spare cycles, maybe you could have helped them. seems they're hitting some PowerVR specific things
enyc has joined #maemo-leste
<freemangordon>
well, if they need me, they will find me :)
inky has quit [Ping timeout: 256 seconds]
<Wizzup>
sicelo: maybe they can try to make it work on leste as well, might be easier
<Wizzup>
(as stepping stone)
inky has joined #maemo-leste
<Wizzup>
sicelo: wasn't it armel as wel
<Wizzup>
as well*
<freemangordon>
yes, it is
<freemangordon>
but maybe they chroot
<sicelo>
it is armel, yes. no idea exactly how they do it, but iirc it's not chrooting
<sicelo>
maybe one of us should just try it in Leste. maybe the work would be somewhat trivial, considering these guys are having to battle with musl vs. glibc too
<Wizzup>
on a separate note, what do you guys think about installing some more packages into our base images? they're really plain
<freemangordon>
like?
<freemangordon>
sicelo: I doubt it is trivial, given that gles libs on maemo are armel (thus angry birds does softfp calls)
<freemangordon>
not only gles libs in that regard
<freemangordon>
so, without having all armel libs, there is no way to run that
<freemangordon>
and there are no softfp pvr libs for recent kernels
<Wizzup>
dorian, some gps app, qtwebbrowser, tor support, more themes, mail client, tor
<freemangordon>
makes sense
<Wizzup>
maybe some games
<freemangordon>
Wizzup: btw, will you have some time to look @ qt white background issue?
<dsc_>
net-tools curl screen tmux
<Wizzup>
freemangordon: uvos did that before and we weren't sure about a fix
<Wizzup>
but can take another look
<Wizzup>
if we had a maemo tweaks that would be good to have too
DocScrutinizer has quit [Read error: Connection reset by peer]
<rafael2k>
I hope new kernel will make it harder to burn the keyboard... basically current and power rate limiting and control...
<rafael2k>
:/
<rafael2k>
some vconn power role change patch too
<suppboi>
oooh theres this button on droid 4 spacebar that isnt detected
<suppboi>
the leftmost one
<bencoh>
you mean the OK button?
<bencoh>
ah, nah
<suppboi>
no the spacebar has like 2 buttons on it right?
<suppboi>
the one on the left dont work
<suppboi>
could be my kb tho idk
<rafael2k>
Wizzup: I'll test here first and rebase from your repo... hopefully keyboard support should be stable now
<Wizzup>
rafael2k: yeah let's be swift in case others try our new kernel and it burns their keyboard.
<Wizzup>
(if it is related at all to kernel)
<rafael2k>
Wizzup: that is exactly what I'm thinking...
<Wizzup>
suppboi: in any case let me know what config options you want and I'll add them
<rafael2k>
in the end it seems my power supply was not the best option... but having support in software to avoid over voltage and current seems a must have...
<rafael2k>
(I
<Wizzup>
you think it maybe was your lab psu?
<rafael2k>
(I'll compile the new kernel with our patches with minor mods from what we have now, then we can update asap)
<rafael2k>
yes, I think yes
<suppboi>
yess imma look after that thanks
<suppboi>
Wizzup: i was looking for libGLES_CM.h and the packages that could have it are dependent on conflicting maemo packages and pvr ones too
<suppboi>
i was trying to build openarena
<suppboi>
i made a fork of openarenapandora for droid 4. i built it a while back and it ran nicely on fullscreen
<Wizzup>
suppboi: when did you last update? wrt libGLES_CM.h
<suppboi>
only problem was sdl1.2 not grabbing kb. has that and half screen fullscreen been fixed?
inky has quit [Ping timeout: 256 seconds]
<suppboi>
i cant remember but about 1 month ago i apt upgrade-ed and neither my droid 4 or n900 would boot
<humpelstilzchen[>
Wizzup: I guess we should create a wiki page for that. Collect some programs there for each category and then vote for default one (e.g. personally I prefer modrana over maep)
<freemangordon>
I suggest to add HILDON_IM_CONTEXT_HANDLE_RETURN
<freemangordon>
and to split those 2
<freemangordon>
that will solve applications having issues when getting ENTER instead of RETURN
<Wizzup>
humpelstilzchen[: imo we can also just add both for now
<Wizzup>
freemangordon: ok, I think that makes sense
<Wizzup>
maybe quicknote as well?
<Wizzup>
and yeah we can do a wiki page
inky has joined #maemo-leste
inky has quit [Remote host closed the connection]
<freemangordon>
Wizzup: hmm, won't work, at least not correctly
inky has joined #maemo-leste
<freemangordon>
seems enter/return is being executed on key press
<freemangordon>
while we will change that to ker release
<freemangordon>
*key
<freemangordon>
not good I guess
<freemangordon>
I want to hear from uvos on that one
<Wizzup>
suppboi: in any case you really ought to update or download the latest image because we now use mesa for that stuff even on pvr systems
inky has quit [Read error: Connection reset by peer]
<enyc>
Wizzup: hrrm did the whole 16bpp vs 32bpp etc on n900 ever get improved... iirc many discovered stuff just is buggy when given not 24/32 bits e.g. older 16bpp modes to save ram =)
<freemangordon>
enyc: what is the context?
<freemangordon>
ATM n900 uses 32bpp
<enyc>
freemangordon: i forget details excatly alas, ijjust recall somebody complaining about it and others saying that well they should fix their code etc
<enyc>
freemangordon: it seemed tha all sorts of x/gtk/libs/etc just didn't work on 16bpp any more , or so
<freemangordon>
so, we use 32bpp
_inky has joined #maemo-leste
<freemangordon>
I mean - is there any particular issue?
<enyc>
freemangordon: maybe not, other than ram consumption ;p
<freemangordon>
yeah
<enyc>
freemangordon: you've effectively answered my question in that that was the resolution
inky has joined #maemo-leste
<enyc>
ooi has zramswap been looked at in leste defaults...? on faster cpu machines zram being VERY useful, much as we *like* to avoid swap, there are rpgorams/uses/etc its not so avaidable
<Wizzup>
freemangordon: check @ commit, does this fix the special keys?
<freemangordon>
it should, though I guess we have more issues
<freemangordon>
on d4 esp
<freemangordon>
what is the key combo to display scv?
<Wizzup>
btw. I don't know why we didn't do this, but it looks like beowulf has qt4 still, so maybe we should get maemo qt4 in there as well
<Wizzup>
freemangordon: on n900?
<freemangordon>
on d4
<Wizzup>
hmm
<Wizzup>
I think ok + sym? I really don't remember
* freemangordon
tries
<freemangordon>
omg
<Wizzup>
that means it works?
<freemangordon>
double-press of OK+SYM :D
<freemangordon>
what the?!?
<Wizzup>
hm, double?
<Wizzup>
maybe something is stuck somewhere
<freemangordon>
I see "Fn is locked"
<Wizzup>
ok, so you don't see special keyboard?
<freemangordon>
why OK is Fn?
<freemangordon>
I see it
<Wizzup>
ok, so that shouldn't happen I think (seeing both special keys and that note)
<Wizzup>
we use OK because it's a useless key otherwise
<freemangordon>
but, I have to double-press OK (So "Fn is locked" message to appear) and then I have to press SYM
<Wizzup>
if I do that I don't see it, so def some patch is required
<freemangordon>
this is with master OFC
<Wizzup>
right
<Wizzup>
so it's almost there
<freemangordon>
also no I see 'layout switched' messages on ctr->space
<freemangordon>
*now I
<freemangordon>
not that the layout get switched, but that's another story
<freemangordon>
like, do we have RU HW layout?
<Wizzup>
n900 has that for sure
<freemangordon>
yes, but not d4
<Wizzup>
ok, but we had users try on n900
<freemangordon>
and I was wondering how shall we fix that
<freemangordon>
besides n900
<Wizzup>
it's easier to think about when there is a way to test it I think
<freemangordon>
shall we create every possible layout?
<Wizzup>
I think it just needs xkb data, but also I think the d4 relies on some standard pc xkb file
<freemangordon>
well, you can do me a favor an make a release of HIM
<Wizzup>
so perhaps it already just works
<Wizzup>
we want the release with the fn lock thing ?
<freemangordon>
what do you mean?
<freemangordon>
"fn lock" is just a message
<freemangordon>
I suspect Fn is not sticky
<freemangordon>
on n900 pressing and releasing Fn key keeps it "pressed' until the next key press
<freemangordon>
obviously this does no happen on d4
<freemangordon>
does that make sense to you?
<Wizzup>
the way I would expect it to work is:
<Wizzup>
double fn (OK) press is fn lock, double shift press is shift lock
<Wizzup>
summoning special keys is single OK press and then sym press
<freemangordon>
right, besides that "single OK press and then sym press" does not work
<freemangordon>
on d4
<freemangordon>
but I would say this is because of d4 xkb data
<freemangordon>
on n900 Fn key is 'sticky'
<freemangordon>
pressing it once keeps it pressed until next key press
<freemangordon>
actually on d4 keeping OK pressed changes nothing
<freemangordon>
hmm, why vkb shows on enter key?
_inky has quit [Ping timeout: 256 seconds]
inky has quit [Ping timeout: 256 seconds]
<freemangordon>
false alarm
inky has joined #maemo-leste
<freemangordon>
oh, now scv works fine too it seems
<Wizzup>
ok
<Wizzup>
I'll build in a sec
<freemangordon>
yeah
<Wizzup>
btw, I got a bit excited since I saw we can get maemo qt4 in beowulf, but in buster they removed qt4 all together
<Wizzup>
do you think it's worth it still, to port some things over, or better to go to qt5 right away?
<freemangordon>
qt5
<freemangordon>
we are on our own otherwise
<freemangordon>
also, if we want qt4, just take the one from fremantle
<freemangordon>
it is not *that* old
<dsc_>
pls no qt4 :)
<freemangordon>
(4.7.4 iirc)
<Wizzup>
ok
<dsc_>
unless you have a killer app that is too time consuming to port in the meantime
<Wizzup>
it just has the him input method working and stuff
<Wizzup>
is all
<dsc_>
btw, qt6 is going to problematic for conversations and other QML applications
<dsc_>
qt6's QML is not backward compat. with 5
<dsc_>
qt5 should stay relevant for a while though so no biggie :)
<freemangordon>
ukeyboard kreates lots of variants
<freemangordon>
*creates
<Wizzup>
I never understood what ukeyboard does
<rafael2k>
which quietly disables CONFIG_I2C_MUX=y, I will fix as I'm rebasing to new kernel sub-version
<freemangordon>
creates a pile of HW keyboards
<Wizzup>
rafael2k: ty much appreciated
<rafael2k>
humpelstilzchen[: you mentioned something about pp kernel config too - do you want any change?
<Wizzup>
that was the change I merged
<Wizzup>
the one you linked
<Wizzup>
iirc
<Wizzup>
this makes various sensors work properly
<humpelstilzchen[>
rafael2k: camera doesn't work for me, but it looks like the kernel has all the drivers, just not active. I'm currently checking that
<Wizzup>
freemangordon: so we need to import ukeyboard somehow?
<rafael2k>
humpelstilzchen[: did you load the auto-focus firmware?
<Wizzup>
freemangordon: hm I can't get the special keyboard to show yet, anything else I should try/do?
<humpelstilzchen[>
rafael2k: not yet: "ov5640 3-004c: ov5640_set_ctrl_focus: no autofocus firmware loaded"
<rafael2k>
humpelstilzchen[: let know how your camera experiments go, today I plan to advance in kernel testing in order to sync with latest mobian kernel
<humpelstilzchen[>
rafael2k: well good news that the kernel has already all the patches. I tried the kernel config from megi in the maemo kernel and the camera works. So its just a configuration issue which makes things obviously a lot easier
<rafael2k>
humpelstilzchen[: list all the drivers loaded with megi's config
<freemangordon>
Wizzup: what did you do?
<Wizzup>
freemangordon: upgrade, reboot, open osso-xterm, press ok + sym
<Wizzup>
anything else we need to rebuild perhaps?
<rafael2k>
humpelstilzchen[: also, send us which software are you using to test the camera... I suspect I have a small issue in current kernel which was fixed 4 days ago in git already (a PR Wizzup already applied)
<freemangordon>
Wizzup: no
<freemangordon>
lemme upgrade and see
<Wizzup>
ok
<humpelstilzchen[>
rafael2k: unfortunately I can't list the drivers in use that are built in. At least I have not found a way. And its quite a mess, drivers in one config are in kernel in the other module
<humpelstilzchen[>
rafael2k: ah, thx, might missed that
<Wizzup>
rafael2k: I might misunderstand it, but I thought that was his PR
<humpelstilzchen[>
just checked logs, that was my config change :)
<rafael2k>
ah
<freemangordon>
Wizzup: WFM, lemme reboot, just in case
<rafael2k>
eheheheh
<rafael2k>
so may be it was the other way around?
<rafael2k>
lemme do some testing, but that PR definitelly has problems too
<rafael2k>
just to understand - with that PR applied camera works (or the other way around... I got confused)
<humpelstilzchen[>
rafael2k: that PR was for the ambient light/proximity sensor
<humpelstilzchen[>
if it works you get /sys/devices/platform/soc/1c2b000.i2c/i2c-1/1-0048/iio:device1/in_proximity_raw
<rafael2k>
humpelstilzchen[: right, tks. any reason to remove CONFIG_I2C_MUX=y ?
<freemangordon>
Wizzup: close and reopen xterm
<humpelstilzchen[>
rafael2k: that was automatically done my menuconfig
<humpelstilzchen[>
s/my/by/
<freemangordon>
we have this issue on boot
<freemangordon>
vmb does not show up if you open xterm too soonb
<rafael2k>
humpelstilzchen[: ok!
<freemangordon>
not sure how to fix that
<rafael2k>
humpelstilzchen[: so we still need some tweak in config for camera, right?
<humpelstilzchen[>
rafael2k: Yes
<rafael2k>
humpelstilzchen[: right, so I'll try also to play with hm5065, ov5640 and gc2145 drivers to see if we get cameras alive in next build
<freemangordon>
Wizzup: we shall spend some time thinking how to support HW layouts without Nokia hacks
<Wizzup>
freemangordon: I did reboot, but ok, let me try again
<freemangordon>
not reboot
<freemangordon>
restart xterm ;)
<freemangordon>
*osso-xterm
<Wizzup>
yes, but reboot should count as 'restart osso-xterm' I think
<freemangordon>
like, you should be able to open vkb by pressing in osso-xterm window
<freemangordon>
no
<freemangordon>
30 or so sekonds after reboot VKB does not work
<Wizzup>
in any case yes, that works, if keyboard is closed and I press, I see vkb
<Wizzup>
but not special keys
<freemangordon>
ok, open the kbd and press OK and shift
<Wizzup>
oooooooo
<Wizzup>
I keep pressing ok + sym
<freemangordon>
:)
<Wizzup>
ok, yes, that works!
<freemangordon>
second kes has always been ctrl
<freemangordon>
*key
<freemangordon>
BTW, I think SYM key should be Fn, not OK key
<freemangordon>
what is SYM used for?
<Wizzup>
alt
<Wizzup>
we have proper alt :)
<freemangordon>
what exactly for?
<freemangordon>
do we have del?
<freemangordon>
without that alt is useless :p
<inky>
are you talking about hw kbd layouts? aren't those xkb maps?
<Wizzup>
freemangordon: alt is useful in terminals
<Wizzup>
also in many applications
<Wizzup>
I think [OK] is a fine fit, since sym is where alt is naturally
<freemangordon>
inky: yes, but obviously we lack the knowledge to properly extract the available variants and but them in the list
<freemangordon>
*put them
<Wizzup>
so the problem is some gconf values are not populated?
<freemangordon>
no
<freemangordon>
the problem is that gconf values are for n900
<freemangordon>
and that 'ru' is hardcoded
<freemangordon>
and whatnot
<Wizzup>
ok, but that means we should be able to make it work on n900 at least?
<freemangordon>
it should work there
<freemangordon>
but I want this to work properly evewrywhere
<freemangordon>
inky: do you know how to do that ^^^?
<inky>
no, i was trying to understand what the situation is. wanted to ask more quesions. like:
<inky>
so there is a xkb file for nokia
<inky>
and
<inky>
gconf values for nokia n900
<inky>
that replicate each other?
xmn has joined #maemo-leste
<inky>
how gconf values get populated for n900 - automatically at cuntime or hardcoded somewhere? is there a package with n900 gconf layouts ? didn't ask because did not want to spend your energy on explaining.
<inky>
i added vkb layouts from ukeyboard creator, and corresponding fonts. did not deal with hwkbd at all.