System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
Daanct12 has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
xmn has quit [Remote host closed the connection]
System_Error has quit [Remote host closed the connection]
DFP has quit [Quit: Leaving]
System_Error has joined #maemo-leste
xmn has joined #maemo-leste
xmn has quit [Remote host closed the connection]
xmn has joined #maemo-leste
xmn has quit [Remote host closed the connection]
xmn has joined #maemo-leste
joerg has quit [Ping timeout: 252 seconds]
joerg has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
_fab has quit [Quit: _fab]
<sicelo>
add it.
ceene has joined #maemo-leste
_fab has joined #maemo-leste
akossh has joined #maemo-leste
xmn has quit [Ping timeout: 276 seconds]
narodnik has joined #maemo-leste
pere has quit [Ping timeout: 244 seconds]
pere has joined #maemo-leste
akossh has quit [Ping timeout: 265 seconds]
akossh has joined #maemo-leste
norayr has quit [Ping timeout: 252 seconds]
akossh has quit [Ping timeout: 244 seconds]
<Wizzup>
yeah
Anasko has quit [Ping timeout: 260 seconds]
akossh has joined #maemo-leste
pabs3 has quit [Read error: Connection reset by peer]
pabs3 has joined #maemo-leste
<sicelo>
btw how to passthrough a modem into qemu? last night i wanted to use my laptop's modem in leste vm
<sicelo>
i added `-device usb-ehci,id=ehci -device usb-host,id=modem0,vendorid=0x0bdb,productid=0x193e` in my qemu command line, but that didn't seem to have any effect
System_Error has quit [Remote host closed the connection]
<inky>
i thought maemo uses own forks of gtk2, gtk3 and qt for him to work.
<inky>
no qt?
<freemangordon>
qt is not forked
<inky>
oh
<freemangordon>
it has maemo platform plugin
<freemangordon>
gtk3 is not forked as well
<inky>
what did you do with gtk3?
<freemangordon>
rephrase, I don't understand the question
<inky>
and if qt has platform plugin, what dsc is trying to improve?
<inky>
i remember you was working on gtk3 and
<freemangordon>
we don;t have qt plugin for maemo vkb
<inky>
since that vkb works in dino let's say.
<freemangordon>
this is what dsc__ is doing
<freemangordon>
I made gtk3 input method plugin
<freemangordon>
well, ported gtk2 one
<freemangordon>
but that does not mean qt applications have vkb because gtk3 ones have
<dsc__>
<inky> and if qt has platform plugin, what dsc is trying to improve? <== platform plugin != input handling module, there are different types of plugins for Qt, they are under "/usr/lib/x86_64-linux-gnu/qt5/plugins", O
<freemangordon>
:nod:
<dsc__>
I'm working on a "platforminputcontext" for qt5, which works with hildon/him for its vkb
<freemangordon>
ther is also maemo5 style plugin
<inky>
okay i didn't know vkb doesnt work with qt.
<dsc__>
freemangordon: indeed
<freemangordon>
inky: it does not
<inky>
i probably forgot since for months i use only my friend's coolkbd, which is abre to enter characters everywhere.
<freemangordon>
maybe we shall ask your friend to work on HIM vkb and make it working everywhere :)
<dsc__>
yes please :)
arno11 has joined #maemo-leste
<arno11>
dsc__: nice @vkb :)
<inky>
> maybe we shall ask your friend to work on HIM vkb and make it working everywhere :)
<inky>
he won't. he likes to write own things. but
<inky>
* i can package coolkbd and write a wiki page on how to use it.
<inky>
* i can port all vkb language configurations to coolkbd
<inky>
or
<inky>
* i know what did he do. i can work with someone who understands vkb and i think if they eliminate that window which opens to write to buffer, and catch what vkb buttons show, then there's a function in xorg which adds that button to the current layout. and it can be used.
<Wizzup>
mkf: if you get stuck on unlocking or #maemo is not response, do ask again here and we can try to help
<Wizzup>
s/response/responsive/
<tmlind>
freemangordon: starting uart gsm mode from the phy driver makes sense to me, but not so sure about the audio driver accessing /dev/gsmtty instances though..
<freemangordon>
tmlind: yeah, for 2 days I am thinking of it, not a good idea
<freemangordon>
serdev_ngsm seems the proper way, but with doing dlci links serdev too
<freemangordon>
not sure how easy would be to achieve that
<freemangordon>
arno11: do we have caltool installed on leste n900?
<tmlind>
freemangordon: yup dlci links serdev too would be ideal
<freemangordon>
yeah, buty I am not sure when (and if) I will have time and will to do it
<freemangordon>
*but
<freemangordon>
given that so far motmdm is the only user
<arno11>
freemangordon: @caltool, apparently not
<freemangordon>
devlocktool?
<freemangordon>
arno11: ^^^
<freemangordon>
I have it in the VM
<freemangordon>
on d4 too
<arno11>
i have libdevlock-bin
Livio has joined #maemo-leste
<arno11>
i don t have devlocktool
<freemangordon>
it is in libdevlock-bin
<freemangordon>
tmlind: not sure what to do :(
<freemangordon>
sicelo: tmlind said you mentioned some usermode daemon to control audio instead of alsa, could you elaborate?
<arno11>
freemangordon: ah ok
<freemangordon>
tmlind: so, do you know - in order dlci link to become serdev device, shall I create uart device for each link? or, tty device is enough?
<freemangordon>
if latter, then creating new tty driver is the proper way, or?
<sicelo>
freemangordon: tmlind: i don't think it's useful/related to the d4 issue(s). although i don't fully remember what it was, i guess it was either callaudiod or wys, or even eg25-manager.
totalizator has joined #maemo-leste
<tmlind>
freemangordon: each dlci is really packet data at that point.. a tty should not be needed
<freemangordon>
so just register serdev? but then, how would it appear in /dev?
<tmlind>
there is no /dev entry, it's all kernel except for the ones that need a tty and a /dev entry for userspace access
<freemangordon>
sorry for maybe stupid questions, but I am not really into guts of uart/tty/serial bus
<freemangordon>
so, you say we shall not expose any dlci to userland?
<tmlind>
there is a mask in the dts files with the ngsm patches for the dlci that get the /dev entry created
<freemangordon>
I mean - volume control dlci stays in kernel (so no /dev), but what about the others?
<freemangordon>
yes, I saw that
<tmlind>
well gnss allows writes over the /dev/gnss so no dlci needed there either
<freemangordon>
but, if I am to implement each dlci as serdev, wouldn;t we want unused (by kernel) links to be userspace exposed?
<tmlind>
the unused ones could have n_gsm created /dev/gsmtty
<tmlind>
no, serdev is for kernel drivers
<freemangordon>
ah, I see now
ceene has joined #maemo-leste
<tmlind>
then the protocol layer whatever bluetooth/gnss/audio exposes stuff to userspace
<freemangordon>
ok
<freemangordon>
got it
<freemangordon>
so, do you have a link to the latest serdev_ngsm version on lore, I want to see the commets/requirements
<tmlind>
i guess rather the kernel device framework like bluetooth/gnss/audio (instead of protocol layer..)
<freemangordon>
yeah, got it
<tmlind>
just search for gsm serdev in lore and they should all come up
<freemangordon>
or, what is the lates version setn?
<freemangordon>
ok
<tmlind>
so maybe the only thing that is really needed is.. make the child device read/write use serdev
<tmlind>
instead of the custom read/write functions
<freemangordon>
ok, will have a look during the holidays
<tmlind>
ok
<tmlind>
freemangordon: i think serdev gsm may need to just call serdev_controller_add() for each dlci?
<tmlind>
and i guess serdev_device_add()
<freemangordon>
ok, will have a look at how it's done for normal serdev devices, thanks for the hint
Livio has quit [Ping timeout: 264 seconds]
<tmlind>
freemangordon: hmm i guess ideally one serdev controller (which we might already have) that calls serdev_device_add() for each dlci? this just based on memory though..