<Entitlement>
buZz - [ main · slonopotamus/n8x0-overlay Wiki · GitHub ]
<buZz>
i feel leste is possible, but not really sure how much work it'll be :P
<uvos>
buZz: should not be to hard
<buZz>
first gonna try this gentoo to see what the performance even is
<uvos>
buZz: but it will get to hildon-desktop and be out of ram
<buZz>
its just 128mb?
<buZz>
if its 256mb, it should be ok-ish
<buZz>
ah, indeed 128mb :P
<buZz>
my droid4 after booting has 113mb in use
<uvos>
yeah
<uvos>
you can get it down to 90 or so
<uvos>
even then...
<buZz>
posh
<buZz>
:D
<enyc>
buZz: technicality: pre-n900 rely on hardware joypad centre button mapped to 'enter' and a whole load of logic, which has been changed in leste now.
<buZz>
still curious about it
<uvos>
enyc: that dosent matter really
<uvos>
it will work
<enyc>
uvos: sure, thought as much, and I guess the keymap can have that button mapped to something more useful if helpful
<enyc>
uvos: interesting the work sorting out that old broken-ui-spec swap seemed to fix many different issues at once if I understand it
<buZz>
at least n810 -also- has a enter :)
<uvos>
enyc: sorta, that pr had other parts that independantly fixed stuff
<enyc>
uvos: what else was going on? I only modelled as 'special enter key handling' and something about vkb popup
<uvos>
well it was all special enter key handling
<uvos>
but the swap was only one thing
<uvos>
the other thing was that the enter keys (both kp_enter and enter) got redirected though libhildon
<uvos>
on and the vkb pluginns
<uvos>
that was the cause of more bugs than the swap
<enyc>
uvos: curious, how did the 'redirected through' work? -- only for apps compiled with hildon-input-method -- xterm or other native x11 non-maemo app would bypass?
<uvos>
all apps that use libhildon and gtk2
<enyc>
uvos: customized gtk2 ?!?
<uvos>
yeah
<uvos>
so x gave the enter key via xinput to gtk2 then ignored it and used libhildon to send the enter key to him via x using a custom atom. him then sent the enter key to the vkb. the vkb then did absolutly nothing with the key except send it back to him. him then sent the enter key to x via a to the gtk2 application where this all started using a different custom atom and libhildon
<uvos>
also this absurd Rube Goldberg machine was full bugyness
<enyc>
uargh!
<enyc>
uvos: I see this may have been hard to figure out....
<enyc>
I've been grumbling about the swap part in particular but also idefinitfied there are wider issues to sort out .... I guess you just went 'this is silly' and hhad time to look into it properly?
<uvos>
so x gave the enter key to the gtk2 application via xinput. gtk2 then ignored it and used libhildon to send the enter key to him via x using a custom atom. him then sent the enter key to the vkb. the vkb then did absolutly nothing with the key except send it back to him. him then sent the enter key to x via a custom atom. x deliverd the key to the gtk2 application where this all started using a different custom atom and
<uvos>
libhildon.
<uvos>
(corrected)
<uvos>
the best thing about this
<uvos>
is that the enter key ends up in an X11 message buffer a total of 6 times before it is deliverd
<enyc>
I wonder why it worked like that mess in the first-place...
<uvos>
yeah i was trying to make the vkb type into plain x windows and thought 'this is silly'
<enyc>
uvos: so, what is the state of onscreen-kb anyhow, now?
<uvos>
enyc: hmm?
<enyc>
well, does vkb now work with all x apps ?
<uvos>
yes
<uvos>
but only ascii
<uvos>
we had this yesterday
<uvos>
er fr.
<uvos>
and you have to open it manualy
<uvos>
we can fix that later
<enyc>
uvos: I should check over and review carefully the extended hardware keyboard nontheless