<tmlind>
so looks like weston-simple-dmabuf-egl works ok with current wlroots and gles2_texture_from_dmabuf_buffer works ok
<tmlind>
looks like weston-simple-dmabuf-egl --drm-render-node=/dev/dri/card0 option is needed, otherwise it won't work. also needed for wlroots-0.14.0
<tmlind>
so only weston-simple-egl is broken with current wlroots head, but works with wlroots-0.14.0
<tmlind>
maybe fd confusion between drm cards as the renderer is a separate card
<tmlind>
to me it looks like drmPrimeHandleToFD is not getting the right fd for weston-simple-dmabuf-egl
<tmlind>
freemangordon, uvos: also glamor could get confused with the fd to use, worth checking
uvos has joined #maemo-leste
SpiderOnAFly has joined #maemo-leste
Dromyun has joined #maemo-leste
SpiderOnAFly has quit [Ping timeout: 245 seconds]
<uvos>
glamor uses prvk dri device only
<uvos>
or rather only the device you tell it to use
<uvos>
if you specify omapdrm it works fine (in software rendering ofc)
<uvos>
freemangordon: if its just calling it via dbus thats fine maybe, still a bit annoying for packaging (it should maybe just use modest if available at compile time) the problem for me with this being dependancies that for instance would later force us to port everything to gtk3 at the same time before anything works. that kind of thing is not acceptable
<uvos>
like if to port the calendar ui or watever to gtk3 i have to also port modest which means i have to port abook and hildon-home and hildon-desktop and so pushing us into a corner where we have to port everthing at the same time. this makes mantaining these things nigh impossible since you cant test any componant untill you port everything, and the dependancie on hildonized gtk2 also makes incoperating these things in other distros
<uvos>
impossible.
<uvos>
so this kind of dependacy must be avoided imo
<uvos>
as it would be taking us imo further away from maintainablity and also what would be my personal eventual goal that leste could cease to exist as a distrobution and simply be a project like kde or whatever that provides a ui/telephony/etc solution for distros to package along side all the other normal DE they pacakge.
xmn has joined #maemo-leste
zhxt has quit [Ping timeout: 252 seconds]
<Wizzup>
uvos: yes the connui-cellular port is not ready yet for primetime
<Wizzup>
uvos: libgofono was a bit hard to fit into the connui-cellular API
<uvos>
Wizzup: i know, im just reporting
<uvos>
Wizzup: the architecture of the status menu is simply bad, but thats another topic
<Wizzup>
mhm
<Wizzup>
I think it's not too bad tbh, but ok :p
<Wizzup>
it's optimised for low resource usage
<uvos>
yeah it was sane on n900 maybe
<Wizzup>
uvos: you had more luck with another library for sfone, right?
<uvos>
but i dont think its sane anymore
<uvos>
Wizzup: anyhow maybe (if its not lots additional work) it might be worth it to ditch libgofono
<uvos>
since we have to use something else anyways for all the interfaces libgofono dosent cover
<uvos>
Wizzup: well intels libofono is feature compleate
<uvos>
Wizzup: but i dident end up using it (rather i just used ofono directly) because it dident fit well with the way sphone worked
<uvos>
using ofno directly is pretty sane, so is libofono or writing our own even
<uvos>
we could also extend libgofono
<Wizzup>
I need to look at what the exact problems were again, but I think I had to like call some glib event iteration functions to get the info from libgofono, since it took a while for it to process changes
<uvos>
but libofono is very close in function (and glib usage)
<Wizzup>
that kind of stuff
<uvos>
ok
<uvos>
i havent used libofono at all but its internals looked very sane (i lifted code for sphone)
<uvos>
but im trying to setup pure pvr again rn and the dependacy mess is maddening
<tmlind>
yup.. so the dmabuf issues seem to be related to buggy mesa modifiers handling.. trying to fix
<tmlind>
the chromeos mesa patches as in jonathan's tree do advertise modifiers, but it's buggy so currently disabled
<tmlind>
the ddk-1.17 blobs don't even advertise modifiers which can cause issues guessing the format
<tmlind>
uvos: yup that pvrsrvinit.c totally does the trick :)
Daanct12 has joined #maemo-leste
<tmlind>
oh then i did get weston-simple-egl running too with a temporary test hack of sudo ln -s /dev/dri/card0 /dev/dri/renderD128 after starting sway..
Daaanct12 has quit [Ping timeout: 240 seconds]
<Wizzup>
sounds like progressa
<tmlind>
there's a bug somewhere where /dev/dri/card0 should be returned instead of the render device for dmabuf related ioctls..
<tmlind>
yup getting there slowly
<uvos>
tmlind: nice
<uvos>
i cant get the pure blobs to work atm with our glbc for some reason (dosent want to load dri_pvr.so
<uvos>
)
<uvos>
Wizzup: found out why it was locking up with the mobile conui
<uvos>
freemangordon: ^^^^ is required 95ec1becd1a413a77609629ab4ce73f8c51db11a but not 758d2685c788b19cf71d17fc25d65cba025f7ddd otherwise causes a lockup in certain situations
inky_ has quit [Remote host closed the connection]
inky_ has joined #maemo-leste
Daaanct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 245 seconds]
<kona>
My n900 arrived! Time to party like it's 2009!
<Wizzup>
:)
<Wizzup>
kona: let me know if you'd like a d4 as well, I could ship you one in a few weeks
<kona>
i haven't had any luck sourcing a d4. so maybe?
<kona>
it's always fun to see what people leave on used devices.
<kona>
in this case, email from 2010.
<freemangordon>
uvos: not sure I understand the issue (no PR or commit description)
<uvos>
hd_enumerate_input_devices can get called multiple times
<freemangordon>
ah
<uvos>
XSelectExtensionEvent multiple times has interesting effects
<uvos>
(xorg hangs effectively)
<freemangordon>
wel,, why is not that in the commit message? :(
<uvos>
"avoid regesitering presence more than once to avoid lockup"
<uvos>
i gues "avoid regesitering for presence event more than once to avoid lockup"
<uvos>
would have been enough
<uvos>
the fact that you can use XSelectExtensionEvent to wedge the xserver seams like a bug tho
<uvos>
should maybe report it
<freemangordon>
maybe, but please, for the future, please leave a sentence or 2 to explain what the issue is and how the commit fixes it, ok? example: https://github.com/maemo-leste/dsme/commit/d866deb122101cffec00620947843fea1396568f . See, I am not nitpicking, it is really way easier to review if you know what it is all about, without trying to guess.
<freemangordon>
I think there is no use to raise a bug agains xorg
<freemangordon>
they will silently ignore, most probably
<uvos>
not if it affects xwayland :P
<freemangordon>
hmm, right :)
<freemangordon>
does it?
<freemangordon>
BTW, what are the chances to run h-d on xwayland?
<freemangordon>
in theory it should run, no?
<uvos>
should exist
<uvos>
the same extension exists
<uvos>
yeah should run
<freemangordon>
we shall try to start it someday
<uvos>
but accelerated xwayland on d4 is hard/impossible
<freemangordon>
glamor?
<freemangordon>
isn't it the same as with ordinary x?
<uvos>
there where other problems tmlind was investigating
<uvos>
ask him
<freemangordon>
maybe we shall follow the stream and focus on xwayland instead of trying to resurrect yet another dead man (xserver)
<freemangordon>
(just thinking out loudly)
<uvos>
maybe
<uvos>
ultimately we need to replace h-d really
<uvos>
but thats nigh impossible manpower wise ofc
<freemangordon>
kona: BTW, I am on holiday starting tomorrow for a week
<freemangordon>
so far you have wpeditor in the repo
<freemangordon>
so you can install it
<kona>
yes, it's installed for me :)
<freemangordon>
I am going to fulfill another modest dependency when I am back
<freemangordon>
calendar-widgets that is
<freemangordon>
but for now you may simply remove it temporarily while I finish the REing
<kona>
ok!
<freemangordon>
if remove it from debian/control that is, configure.ac is already smart enough to deal with that
<freemangordon>
basically, if there is no calendar-ui-widgets pkgconfig package, modest will use HildonColorPicker instead of PipColorPicker (pip_color_picker_select_color())
<freemangordon>
Not that I know the difference :)
<freemangordon>
also, it seems modest-providers-data is included as dependency, but not really used
<freemangordon>
kona: one question - do you rewrite tinymail gnomevfs module with gio or do a copy of it to be ported to gio
<uvos>
and that calls XCloseDevice on every device
<freemangordon>
basically we get (possibly) different xi_motion_ev_type value for every call, no?
<uvos>
sure yeah you get it for the last device more or less
<uvos>
thats "fine"
<freemangordon>
ok, if you say so I am not going to argue, but it looks suspicious to me, like, why event id for the last device is the same as for the others?
<freemangordon>
it is the same because the class is the same?
<freemangordon>
*is it
<uvos>
not sure if its defined to be so
<uvos>
but it is in practice
<uvos>
im reading docs rn to see what i can find
<freemangordon>
ok
<freemangordon>
going to fix those static vars in the meanwile
<freemangordon>
uvos: have a look at FindTypeAndClass macro