<tmlind>
maybe ping uvos about it when he's around, i'll be gone in few mins
xmn has quit [Remote host closed the connection]
pere has quit [Ping timeout: 265 seconds]
pere has joined #maemo-leste
Mighty has quit [Quit: Connection closed for inactivity]
uvos has joined #maemo-leste
<uvos>
can we have sdl with --enable-video-kmsdrm?
<uvos>
parazyd:
ikmaak2 is now known as ikmaak
<uvos>
tmlind: that patch seams to solve the issue :)
R0b0t1 has quit [Ping timeout: 268 seconds]
R0b0t1 has joined #maemo-leste
<parazyd>
uvos: Are you talking about sdl2 or sdl1.2?
<uvos>
parazyd: sdl2
<uvos>
i have modified charging-sdl to work on d4, to exit when a rtc alarm fires, to exit when charging stops and to only run when charging is enabled.
<uvos>
i also made a runlevel that just starts charging-sdl and then runs the default runlevel or shuts down depending how charging-sdl exits
<uvos>
tldr working charging mode
<uvos>
however i need sdl2 pacakged with --enable-video-kmsdrm
<uvos>
and parazyd do you have a idea how to have a package crate a openrc runlevel in a sane way?
<parazyd>
uvos: I could try lobbying upstream Debian to enable that for future releases, and we can fork it for Beowulf I suppose
<parazyd>
uvos: For the runlevel, it is enough to create a directory in /etc/runlevels
<parazyd>
So do that either with a Makefile or with a debian/foo.install
<parazyd>
And you can add initscripts to it via a debian/postinst
<parazyd>
rc-update del foo default; rc-update add foo customrunlevel
<parazyd>
If you want it to completely clean up after a remove/purge, then make sure debian/postrm also unlinks that symlink or just does a rm -rf
<parazyd>
(On /etc/runlevels/customlevel)
<uvos>
ok ill try to package it as soon as we have the prerequisite sdl
<parazyd>
Alright. I'll try to do it tomorrow. Currently finishing up a blog post :)
<parazyd>
newsnewsnews
<parazyd>
:D
<parazyd>
uvos: That configure flag isn't exclusive to some other flag, right?
<uvos>
parazyd: no and the newer cmake build system builds it by default
<inky>
people, please review/accept the commit regarding the keyboard. not mine, but we talked about it. the one that would allow maemo keyboard to send characters to regular debian programs.
<inky>
i just cannot without it. (:
<uvos>
inky: its there
<uvos>
in devel
<inky>
hm, i updated several days ago.
<inky>
oh.
<inky>
i did not know about devel.
<inky>
wait let me find out in wiki where is devel.
<uvos>
what device are you on?
<inky>
droid4
<uvos>
ok not sure why you would want to use the vkb.. its uh. bad :P
<inky>
well because my native language doesn't use latin characters (and i am the commiter of all previous vkb keyboards to leste)
<uvos>
oh ok
<inky>
and most of my communications, and even some domain names i type are in armenian.
<uvos>
the vkb wont help you currently
<inky>
so i need to use vkb.
<uvos>
wont help you
<inky>
why?
<uvos>
the x11 backend supports us chareters only atm
<parazyd>
hmm that's not convenient for an entire alphabet
<uvos>
parazyd: no
<uvos>
really someone should write a tool that parse keysymdef.h
<parazyd>
Parse in what way?
<uvos>
parse vs unicode names
<uvos>
should be ok with a fuzzy match
<uvos>
since the names in keysymdef are sane mostly
<uvos>
but yeah its not great
<inky>
wait, what do you get from vkb - unicode text stream?
<inky>
or something else?
<uvos>
inky: yeah unicode text stream
<uvos>
inky: and then we need xkeysyms somehow
<uvos>
so we can map those to xkeycodes
<uvos>
the next problem is that xkeycodes only exist for syms in the current map
<inky>
trying to understand. you get unicode stream, but you cannot send that to X, so you send keysyms.
<uvos>
yeah you have to send keycodes to x
<uvos>
not keysyms either
<uvos>
but those you can convert easy
<inky>
yeah yeah keycodes.
<inky>
but then it, according to xkb, should choose the characters to type.
<inky>
hmmmm.
<parazyd>
We could have different files for different layouts
<parazyd>
Then it might not be so convoluted
<uvos>
parazyd: ?
<parazyd>
I mean if it has to be done with a switch like that
<inky>
but wait. xkb layouts do not correspond to our vkb layouts.
<uvos>
here listen for a second
<uvos>
so
siceloa has left #maemo-leste ["User left"]
<uvos>
input in x works like this: if you want to send a symbol like lets say EPSILON. you have to first transpose it into a keycode witch is 0-255 via the keymap. you can ask x to do this for you.
<uvos>
the client that you sent the code then takes it and asks x "whay symbol is this" and x transforms it int a sym again based on the keymap
<uvos>
as there are only 255 keycodes availble the map cant have every symb.
<uvos>
so if you try to send a symb. that not on the map it fails
<uvos>
the way other vkbs work around this is they modify the keymap for 1 second or there about send the keys and change it back
<Wizzup>
heh
<uvos>
sadly due to a x protocoll limitation this is the only possible way
<Wizzup>
I got stuck with some of this in the qt5 port (mapping qt5 keysyms to things to send to h-i-m)
<uvos>
as the keycode is 8 bit
<uvos>
so rn
<uvos>
if inky adds his symbols to the switch-case it will send all the codes it can and the others it will wan about.
<uvos>
if he sets his keymap to also include the symbols he wants everything will work
<uvos>
and then we can additionally implment the workaround above
<uvos>
(but its terribly racey)
<uvos>
since you can guarentee that x will change the keymap in time
* inky
searching for that repo with layouts i commited
<Entitlement>
inky - [ hildon-input-method-plugins/hy_AM.xml at master · maemo-leste/hildon-input-metho... ]
<inky>
but here we have unicode characters and layout only.
<uvos>
inky: thats right, the vkb uses that to give him the unicode text stream
<uvos>
inky: and him then must either give this wholesale to the client if it can (via the custom him protocol atoms) or if it needs to fall back to plain X it needs to tansfrom these to keycodes somehow, and since the keycodes are diferent depending on hwkbd map we want them in xkeysyms.
<uvos>
since the keysyms are static and we can have x deal with the translation to keycodes
<inky>
so ok, sorry i am slow to understand.
<inky>
what i don't understand is
<inky>
lets say we converted unicode character to keycode.
<inky>
i don't even know how to express this.
<inky>
you mean, we need to change the xkb layout, then send the keycode, that in that xkb layout corresponds to the unicode character we send?
<inky>
so we also need to change xkb layout?
<inky>
otherwise how we get the keycode from the unicode character?
<inky>
the keycode only makes sense if there is xkb layout. no?
<uvos>
yeah so the charecter you want to send needs to be in the xkb layout somewhere
<uvos>
due to how x works you cant send a greek delta or whatever if its not in the xkb layout
<inky>
then may be it is easier to get rid of our vkb keyboards, and generate new vkb layouts based on xkb...
<inky>
oh that's too many layouts then...
<inky>
i am thinking of beautiful solution for every layout/language, and cannot find it.
<uvos>
inky: problem with that is that in no way do we want the hwkb to need to be the same as the vkb
<uvos>
on d4 for instance if you change xkb map to include the XK_ARMENIAN symbols the hwkb will be useless
<uvos>
so they way to do this imo is to change to whatever xkb map has the symbols you want wen the vkb is open, and hope no one notices that by trying to type on the vkb and hwkb at the same time.
<uvos>
or switch to wayland
<uvos>
problem totaly goes away with wayland.
<uvos>
since it uses 32bit keycodes
<parazyd>
Can the X clipboard help with this in any way?
<uvos>
X dose have a very seldomly used 3rd clipboard
<uvos>
that would work for some input fields but problem with that is that many applications simpy want keycodes
<uvos>
for many interactions
<parazyd>
True
<uvos>
also the 3rd clipboard only works with some toolkits
<uvos>
gtk3 for instance totaly dosent register it
<parazyd>
It could be any clipboard really
<parazyd>
But yeah, it's not ideal
<uvos>
and useing the 1 or second clipboard would overwrite the stuff the user has in it
<uvos>
i gues you could save it and then restore it
<Entitlement>
parazyd - [ GitHub - maemo-leste/clipboard-manager: The clipboard manager is responsible for... ]
<uvos>
but then we are in the weeds again just like with the keycoads ;)
<parazyd>
Yeah yeah, was just a random idea
<inky>
ok
<inky>
i have an idea
<uvos>
parazyd: its not bad :)
<inky>
we can hardcode (not a good word but still)
<inky>
the map - our vkb layout - xkbmap that contains those symbols that come from vkb layout
<uvos>
inky: yeah that works
<uvos>
to an extent
<uvos>
but you only have 255 keys total
<inky>
let's say my hy_AM.xml uses symbols that are in 'am' xkb map.
<uvos>
so you cant map everything
<uvos>
you could map all the d4 keys
<uvos>
and have many left over for sure
<inky>
i don't need to use hwkb for armenian. i want to use on screen kbd. one day i'll get a pinephone, and it has no hw kbd.
<uvos>
but doing this for every language is a huge undertaking
<parazyd>
I mean, two alphabets for sure fits in the 255
<parazyd>
So the vkb could be switched on a per-need basis
<inky>
i mean, will that solve the issue if
<inky>
i get you a mapping - this xml corresponds to this xkb layout?
<uvos>
inky: i dont need that
<uvos>
i just need a way to trasfrom unicode to xkeysymbs
<uvos>
all xkeysymbs are allways available
<uvos>
so the vkb frontend dosent have to care about anything else.
<inky>
i don't know what is xkeysyms probably. i know keycodes, and i know unicode.
<inky>
let me see
<uvos>
so xkeysymbs are a mechanisum x uses to tell applications what a keycode is suposed to mean right now
<uvos>
so if we map keycode 42 to A in xkb the applicaiton just gets sent 42
<uvos>
to then know what to print
<uvos>
it asks X what is 42?
<uvos>
and the awnser it gets is the xkeysymb for A
<uvos>
xkeysymbs are kinda like unicode
<uvos>
just old and bad :P
<uvos>
the key here being that if you change the xkb map so that your A key on the keyboard is now keycode 66 the application will still get the same xkeysymb A if it asks x what is 66.
<uvos>
inky: did that clear it up for you?
<parazyd>
uvos: Would XStringToKeysym function work?
<uvos>
parazyd: haha
<uvos>
parazyd: no
<parazyd>
?
<inky>
i found that xkbcommon/xkbcommon-keysyms.h contains the symbols used in xkb configs.
<uvos>
parazyd: i use that
<uvos>
parazyd: it only dose A-Z a-z and 0-9
<inky>
i think that works only for alphanumericals
<uvos>
thats why those are not in the switch case
<parazyd>
oh lol
<inky>
yes. just read that.
<parazyd>
ok
<uvos>
acctually what it dose
<uvos>
is it transforms the keysymb name to its value like "XK_Armenian_but" to 0x100055d
<uvos>
but not "blabala" to various values
<uvos>
except that A-Z and a-a and 0-9 are named literaly
<parazyd>
I see
<inky>
ok i think i can write a parser you need. just explain me better what i need to generate.
<inky>
i can generate some header file for you with definitions.
<inky>
or some map that you can use instead of that switch.