| uvos | so the adress book depends on a specific email client which depends on a calandar widget which is a plugin for a program that depends on hildon-desktop and in turn allmost everything hildon which also depends on the calendar backend | 00:32 |
|---|---|---|
| uvos | clearly this is not sane and a cut needs to be made in some (or better several places) here | 00:33 |
| freemangordon | uvos: Well, the dependency is not that tight, it is more or less like calling xdg stuff: https://pastebin.com/CiWmK7F4 | 07:47 |
| freemangordon | also, email client *does not* depend on calendar widget, but on a library that provides common ui elements | 07:49 |
| freemangordon | it just happens that this library is part of calendar-ui, which I agree is a bad design | 07:49 |
| freemangordon | however, maemo *is* hildon, like it or not, once we dehildonize it, it will be no more maemo but something else | 07:50 |
| freemangordon | WTF is 'Pip' supposed to mean in PipCalendarDialog, PipCalendarColor and PipColorPicker?!? | 08:33 |
| freemangordon | uvos: also, modest conditionally use color picker widget from calendar, it is #ifdef-ed | 09:00 |
| freemangordon | this 'pip' drives me nuts, it is all over the place in calendar-ui, without a single hint what its meaning could be | 09:12 |
| freemangordon | none of https://acronyms.thefreedictionary.com/PIP make any sense to me in the context. Anyways, I am going to rename it | 09:19 |
| tmlind | so looks like weston-simple-dmabuf-egl works ok with current wlroots and gles2_texture_from_dmabuf_buffer works ok | 09:43 |
| 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 | 09:44 |
| tmlind | so only weston-simple-egl is broken with current wlroots head, but works with wlroots-0.14.0 | 09:44 |
| tmlind | maybe fd confusion between drm cards as the renderer is a separate card | 09:45 |
| tmlind | to me it looks like drmPrimeHandleToFD is not getting the right fd for weston-simple-dmabuf-egl | 09:46 |
| tmlind | freemangordon, uvos: also glamor could get confused with the fd to use, worth checking | 09:47 |
| uvos | glamor uses prvk dri device only | 12:32 |
| uvos | or rather only the device you tell it to use | 12:32 |
| uvos | if you specify omapdrm it works fine (in software rendering ofc) | 12:33 |
| 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 | 12:35 |
| 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 | 12:38 |
| uvos | impossible. | 12:38 |
| uvos | so this kind of dependacy must be avoided imo | 12:39 |
| 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. | 12:40 |
| Wizzup | uvos: yes the connui-cellular port is not ready yet for primetime | 14:37 |
| Wizzup | uvos: libgofono was a bit hard to fit into the connui-cellular API | 14:37 |
| uvos | Wizzup: i know, im just reporting | 14:39 |
| uvos | Wizzup: the architecture of the status menu is simply bad, but thats another topic | 14:40 |
| Wizzup | mhm | 14:40 |
| Wizzup | I think it's not too bad tbh, but ok :p | 14:40 |
| Wizzup | it's optimised for low resource usage | 14:40 |
| uvos | yeah it was sane on n900 maybe | 14:40 |
| Wizzup | uvos: you had more luck with another library for sfone, right? | 14:40 |
| uvos | but i dont think its sane anymore | 14:40 |
| uvos | Wizzup: anyhow maybe (if its not lots additional work) it might be worth it to ditch libgofono | 14:41 |
| uvos | since we have to use something else anyways for all the interfaces libgofono dosent cover | 14:41 |
| uvos | Wizzup: well intels libofono is feature compleate | 14:41 |
| 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 | 14:42 |
| uvos | so that was just less work | 14:42 |
| Wizzup | I did quite some stuff but it wasn't ready yet https://github.com/maemo-leste/connui-cellular/commits/ofono-port | 14:42 |
| uvos | ok | 14:42 |
| uvos | using ofno directly is pretty sane, so is libofono or writing our own even | 14:42 |
| uvos | we could also extend libgofono | 14:43 |
| 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 | 14:43 |
| uvos | but libofono is very close in function (and glib usage) | 14:43 |
| Wizzup | that kind of stuff | 14:43 |
| uvos | ok | 14:43 |
| uvos | i havent used libofono at all but its internals looked very sane (i lifted code for sphone) | 14:44 |
| uvos | if you want to try that | 14:44 |
| Wizzup | this kind of stuff: https://github.com/maemo-leste/connui-cellular/commit/cf74cda887e2d09a87635a528856caaf044e1d9c | 14:45 |
| Wizzup | (this is for the pin entry iirc) | 14:45 |
| uvos | ok | 14:45 |
| Wizzup | you can tell by the commit msgs I was getting a bit annoyed | 14:45 |
| Wizzup | however I currently have a strong hangover and I can't reason clearly about it :D | 14:46 |
| Wizzup | I think once tor/wireguard is done (deadline in ~10 days), I will get back to audio, and then probably telepathy+cellular makes sense | 14:46 |
| Wizzup | the commit msgs at least show how much had to be ported | 14:46 |
| Wizzup | but basically it's currently full of hacks | 14:47 |
| uvos | anyone having the problem that the leste kernel dosent shutdown properly? | 16:00 |
| Wizzup | what device? | 16:00 |
| uvos | i just booted it by accident | 16:00 |
| uvos | d4 | 16:00 |
| uvos | my private dev kernel shuts down fine | 16:01 |
| uvos | the leste one dose not | 16:01 |
| Wizzup | I don't think so, could it be related to the new dsme? | 16:01 |
| uvos | (5.11) | 16:01 |
| uvos | new dsme isent tagged out or? | 16:01 |
| Wizzup | it's in -devel afaik | 16:01 |
| uvos | hm maybe the swtich in kernel came at the same time so yeah | 16:02 |
| uvos | have to check | 16:02 |
| uvos | hmm no its something with the kernel | 16:08 |
| Wizzup | I don't think we upgraded the kernel recently did we? | 16:10 |
| uvos | no but i havent used your kernel untill now | 16:12 |
| uvos | i was just swiching from one i built to the vanilla leste one | 16:12 |
| Wizzup | so what do you do, type 'sudo poweroff' and then it resets for you? | 16:13 |
| uvos | it just hangs sudo power off hangs at a blank screen with just a _ | 16:13 |
| uvos | power off via dsme hangs with just the mce light on forever | 16:14 |
| Wizzup | let me upgrade to latest sw and try | 16:14 |
| uvos | works fine with the other kenrel | 16:16 |
| uvos | (should be same thing except i have some wip cpcap patches and a call audio hack applied) | 16:16 |
| Wizzup | could also potentially be related to new mce perhaps | 16:17 |
| Wizzup | let's see | 16:17 |
| uvos | i gues but i have been using that for a long time | 16:17 |
| uvos | (with dev kernel ofc) | 16:17 |
| Wizzup | at least before upgrade to latest mce and dsme 'poweroff' from terminal worked fine | 16:19 |
| Wizzup | booting again | 16:19 |
| Wizzup | uvos: not seeing any problems here | 16:40 |
| uvos | hmm wierd | 16:49 |
| freemangordon | uvos: I agree, more or less, however, it is nopt now the time to start decoupling, lets first have something that works | 17:02 |
| freemangordon | otherwise we'll never end chasing our tail | 17:02 |
| uvos | we need to create a ddk1.17 package | 17:43 |
| uvos | for pure ddk | 17:43 |
| uvos | https://github.com/IMbackK/pvr-omap4 | 17:43 |
| uvos | this works for chomeos mesa | 17:43 |
| uvos | but im trying to setup pure pvr again rn and the dependacy mess is maddening | 17:44 |
| tmlind | yup.. so the dmabuf issues seem to be related to buggy mesa modifiers handling.. trying to fix | 17:54 |
| tmlind | the chromeos mesa patches as in jonathan's tree do advertise modifiers, but it's buggy so currently disabled | 17:55 |
| tmlind | the ddk-1.17 blobs don't even advertise modifiers which can cause issues guessing the format | 17:56 |
| tmlind | uvos: yup that pvrsrvinit.c totally does the trick :) | 17:56 |
| 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.. | 18:00 |
| Wizzup | sounds like progressa | 18:01 |
| tmlind | there's a bug somewhere where /dev/dri/card0 should be returned instead of the render device for dmabuf related ioctls.. | 18:01 |
| tmlind | yup getting there slowly | 18:01 |
| uvos | tmlind: nice | 19:27 |
| uvos | i cant get the pure blobs to work atm with our glbc for some reason (dosent want to load dri_pvr.so | 19:28 |
| uvos | ) | 19:28 |
| uvos | Wizzup: found out why it was locking up with the mobile conui | 19:28 |
| uvos | Wizzup: was not your or its fault | 19:28 |
| uvos | but my fault and a wierd interaction | 19:28 |
| Wizzup | uvos: ok | 19:35 |
| lel | IMbackK opened a pull request: https://github.com/maemo-leste/hildon-desktop/pull/15 (avoid regesitering presence more than once to avoid lockup) | 19:52 |
| uvos | freemangordon: ^^^^ is required 95ec1becd1a413a77609629ab4ce73f8c51db11a but not 758d2685c788b19cf71d17fc25d65cba025f7ddd otherwise causes a lockup in certain situations | 19:52 |
| kona | My n900 arrived! Time to party like it's 2009! | 20:32 |
| Wizzup | :) | 20:36 |
| Wizzup | kona: let me know if you'd like a d4 as well, I could ship you one in a few weeks | 20:36 |
| kona | i haven't had any luck sourcing a d4. so maybe? | 20:59 |
| kona | it's always fun to see what people leave on used devices. | 21:16 |
| kona | in this case, email from 2010. | 21:16 |
| freemangordon | uvos: not sure I understand the issue (no PR or commit description) | 21:31 |
| uvos | hd_enumerate_input_devices can get called multiple times | 21:34 |
| freemangordon | ah | 21:34 |
| uvos | XSelectExtensionEvent multiple times has interesting effects | 21:34 |
| uvos | (xorg hangs effectively) | 21:34 |
| freemangordon | wel,, why is not that in the commit message? :( | 21:35 |
| uvos | "avoid regesitering presence more than once to avoid lockup" | 21:35 |
| uvos | i gues "avoid regesitering for presence event more than once to avoid lockup" | 21:36 |
| uvos | would have been enough | 21:36 |
| uvos | the fact that you can use XSelectExtensionEvent to wedge the xserver seams like a bug tho | 21:37 |
| uvos | should maybe report it | 21:37 |
| 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. | 21:38 |
| freemangordon | I think there is no use to raise a bug agains xorg | 21:40 |
| freemangordon | they will silently ignore, most probably | 21:40 |
| uvos | not if it affects xwayland :P | 21:40 |
| freemangordon | hmm, right :) | 21:40 |
| freemangordon | does it? | 21:40 |
| freemangordon | BTW, what are the chances to run h-d on xwayland? | 21:41 |
| freemangordon | in theory it should run, no? | 21:41 |
| uvos | should exist | 21:41 |
| uvos | the same extension exists | 21:41 |
| uvos | yeah should run | 21:41 |
| freemangordon | we shall try to start it someday | 21:41 |
| uvos | but accelerated xwayland on d4 is hard/impossible | 21:41 |
| freemangordon | glamor? | 21:41 |
| freemangordon | isn't it the same as with ordinary x? | 21:42 |
| uvos | there where other problems tmlind was investigating | 21:42 |
| uvos | ask him | 21:42 |
| freemangordon | maybe we shall follow the stream and focus on xwayland instead of trying to resurrect yet another dead man (xserver) | 21:43 |
| freemangordon | (just thinking out loudly) | 21:43 |
| uvos | maybe | 21:44 |
| uvos | ultimately we need to replace h-d really | 21:44 |
| uvos | but thats nigh impossible manpower wise ofc | 21:44 |
| freemangordon | kona: BTW, I am on holiday starting tomorrow for a week | 21:45 |
| freemangordon | so far you have wpeditor in the repo | 21:45 |
| freemangordon | so you can install it | 21:45 |
| kona | yes, it's installed for me :) | 21:46 |
| freemangordon | I am going to fulfill another modest dependency when I am back | 21:46 |
| freemangordon | calendar-widgets that is | 21:46 |
| freemangordon | but for now you may simply remove it temporarily while I finish the REing | 21:46 |
| kona | ok! | 21:47 |
| freemangordon | if remove it from debian/control that is, configure.ac is already smart enough to deal with that | 21:47 |
| freemangordon | basically, if there is no calendar-ui-widgets pkgconfig package, modest will use HildonColorPicker instead of PipColorPicker (pip_color_picker_select_color()) | 21:49 |
| freemangordon | Not that I know the difference :) | 21:49 |
| freemangordon | also, it seems modest-providers-data is included as dependency, but not really used | 21:50 |
| freemangordon | kona: one question - do you rewrite tinymail gnomevfs module with gio or do a copy of it to be ported to gio | 21:51 |
| freemangordon | ? | 21:51 |
| lel | freemangordon closed a pull request: https://github.com/maemo-leste/hildon-desktop/pull/15 (avoid regesitering presence more than once to avoid lockup) | 22:04 |
| uvos | freemangordon: great | 22:05 |
| kona | Rewrite was my plan, do you have a beret idea? | 22:05 |
| uvos | freemangordon: please coordinate with parazyd on any release of h-d (as the prs require removals and changes to the meta packages) | 22:06 |
| kona | s/beret/better/ | 22:06 |
| kona | Well, rename to libtinymail-gio | 22:07 |
| kona | I don't plan to rename the tinyvfs apis, though | 22:08 |
| freemangordon | kona: what about introduce a copy (libtinymail-gio) and to keep the current gnomevfs plugin | 22:09 |
| freemangordon | It should be the same, no? | 22:09 |
| freemangordon | besides that we'll keep it compatible with fremantle | 22:10 |
| freemangordon | and yes, no tinyvfs rename shall be done | 22:10 |
| freemangordon | uvos: I will, but I want to fix anotehr issue I just saw | 22:10 |
| uvos | not that there is a reason not to but compatability with fremantle is fairly unimportant no? | 22:11 |
| uvos | freemangordon: no rush | 22:11 |
| uvos | freemangordon: im just saying that the old method of rotation needs to go at the same time on user devices :) | 22:11 |
| freemangordon | uvos: https://github.com/maemo-leste/hildon-desktop/blob/6eba1573905ac7b8e36a18ce52776811ef3c456d/src/util/hd-xinput.c#L14 | 22:11 |
| freemangordon | why are those not static? | 22:11 |
| uvos | oversight | 22:11 |
| freemangordon | or rather - is there any particular reason? | 22:11 |
| uvos | no | 22:11 |
| freemangordon | ok, going to fix | 22:11 |
| freemangordon | uvos: re tinymail - it is unimportant, but is more or less free | 22:12 |
| uvos | ok | 22:12 |
| uvos | yeah was just asking it as a policy question | 22:12 |
| freemangordon | we just don;t build gnomevfs module for leste | 22:12 |
| uvos | (ie is fremantle backward compatibilty a goal) | 22:12 |
| freemangordon | besides fremantle, there are 4 or 5 more platforms that are supported | 22:13 |
| freemangordon | includeing gnome desktop | 22:13 |
| freemangordon | so we either remove them all and leave leste only or add leste as another platform | 22:13 |
| freemangordon | I'd say - add leste as another platform given that wit costs no additional overhead | 22:14 |
| freemangordon | *it costs | 22:14 |
| uvos | sure im not opposed | 22:14 |
| freemangordon | kona: what do you think? | 22:14 |
| freemangordon | I have already added mamo-leste platform | 22:14 |
| freemangordon | *maemo-leste | 22:14 |
| freemangordon | uvos: back to h-d: don;t we have the same issue with DeviceMotionNotify() ? | 22:15 |
| kona | Does tinymail even build for the others now? | 22:16 |
| freemangordon | for sure it builds for fremantle | 22:16 |
| freemangordon | and I see no reason to not build for others | 22:17 |
| kona | Ah, hmm. | 22:17 |
| kona | Ok, no problem :) | 22:17 |
| uvos | freemangordon: no because XCloseDevice unregisters all notfiers on the device afaik | 22:17 |
| freemangordon | though I am not sure we shall keep it backward compatible after leste is fully functional | 22:18 |
| freemangordon | but until then... | 22:18 |
| freemangordon | uvos: I mean here https://github.com/maemo-leste/hildon-desktop/blob/6eba1573905ac7b8e36a18ce52776811ef3c456d/src/util/hd-xinput.c#L88 | 22:19 |
| uvos | yeah thats fine | 22:19 |
| uvos | no way that runs twice for the same device | 22:19 |
| uvos | as https://github.com/maemo-leste/hildon-desktop/blob/6eba1573905ac7b8e36a18ce52776811ef3c456d/src/util/hd-xinput.c#L53 | 22:19 |
| uvos | guards it with | 22:19 |
| uvos | hd_close_input_devices | 22:20 |
| uvos | and that calls XCloseDevice on every device | 22:20 |
| freemangordon | basically we get (possibly) different xi_motion_ev_type value for every call, no? | 22:20 |
| uvos | sure yeah you get it for the last device more or less | 22:21 |
| uvos | thats "fine" | 22:21 |
| 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? | 22:22 |
| freemangordon | it is the same because the class is the same? | 22:23 |
| freemangordon | *is it | 22:23 |
| uvos | not sure if its defined to be so | 22:23 |
| uvos | but it is in practice | 22:23 |
| uvos | im reading docs rn to see what i can find | 22:23 |
| freemangordon | ok | 22:23 |
| freemangordon | going to fix those static vars in the meanwile | 22:24 |
| freemangordon | uvos: have a look at FindTypeAndClass macro | 22:26 |
| uvos | https://github.com/D-Programming-Deimos/libX11/blob/master/c/X11/XInput.h | 22:28 |
| freemangordon | it seems it just happens to return the same values for different devices | 22:28 |
| uvos | its allways the same | 22:28 |
| uvos | type = _ip->event_type_base + offset | 22:28 |
| uvos | offset is #define _deviceMotionNotify0 | 22:28 |
| uvos | and _ip->event_type_base is the same if device class is the same | 22:28 |
| freemangordon | so, _ip is the same for every device? | 22:29 |
| uvos | looks like yeah for same input_class | 22:30 |
| uvos | let me check | 22:30 |
| freemangordon | thanks | 22:30 |
| uvos | freemangordon: https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/Xi/opendev.c | 22:34 |
| uvos | it comes from a global here | 22:34 |
| uvos | this really is an implementation detail of xorg | 22:34 |
| uvos | but yeah it looks like its ok | 22:34 |
| freemangordon | yup | 22:34 |
| uvos | i gues a perfectly spec adhering x11 server could do something else | 22:35 |
| freemangordon | ok, going to do a release | 22:35 |
| Wizzup | thanks for being thorough guys | 22:38 |
| freemangordon | uvos: will you have some spare time soon to look at matchboz focus (or whatever it was) issue? | 22:45 |
| freemangordon | *patchbox | 22:45 |
| freemangordon | aaah | 22:45 |
| freemangordon | MATCHBOX | 22:45 |
| freemangordon | :) | 22:45 |
| uvos | freemangordon: sure | 22:52 |
| uvos | rn im still trying to figure out why the pure pvr setup dosent work for me anymore | 22:52 |
| uvos | yeah i dont get it so it goes: | 23:08 |
| uvos | MESA-LOADER: failed to open pvr (search paths /usr/lib/dri) | 23:09 |
| uvos | failed to load driver: pvr | 23:09 |
| uvos | i can LD_PRELOAD=/usr/lib/dri/pvr_dri.so | 23:09 |
| uvos | and then it works | 23:09 |
| uvos | if i strace it goes openat(AT_FDCWD, "/usr/lib/dri/pvr_dri.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 4 | 23:10 |
| uvos | so | 23:10 |
| uvos | not sure whats up with that | 23:10 |
| uvos | freemangordon: any ideas? | 23:12 |
| uvos | freemangordon: what to check even | 23:12 |
| freemangordon | I think we must LD_PRELOAD, otherwise we have issue because of the hacked libc version | 23:13 |
| uvos | thats not great | 23:14 |
| freemangordon | I wonder it works at all even with LD_PRELOAD if you use stock (and not 'hacked') blobs | 23:14 |
| freemangordon | sure it is not | 23:14 |
| uvos | no | 23:14 |
| uvos | ld will just fail immidatly | 23:14 |
| uvos | because it checks the symbols | 23:14 |
| freemangordon | so, those are hacked blobs? | 23:14 |
| uvos | yeah | 23:14 |
| freemangordon | ok, you have to LD_PRELOAD couple of them | 23:15 |
| uvos | just usr/lib/dri/pvr_dri.so works fine | 23:15 |
| freemangordon | won't work otherwise | 23:15 |
| uvos | anyhow maybe we should try and solve the issues that chromeos mesa has | 23:15 |
| uvos | as it needs nothing of the sort | 23:15 |
| freemangordon | doesn;t it need the same blob? | 23:15 |
| uvos | it uses some of the blobs | 23:16 |
| uvos | but not that one | 23:16 |
| uvos | https://github.com/IMbackK/pvr-omap4 | 23:16 |
| uvos | see that | 23:17 |
| freemangordon | so, same shit, they are linked to the newer libc6 | 23:17 |
| uvos | right | 23:17 |
| uvos | but no LD_PRELOAD needed | 23:17 |
| uvos | it just works after weaking the symbol versions | 23:17 |
| freemangordon | hmm, okm | 23:17 |
| uvos | since usr/lib/dri/pvr_dri.so is foss | 23:17 |
| uvos | and compiled against whatever | 23:17 |
| uvos | you want | 23:17 |
| freemangordon | is it? ah. ok | 23:17 |
| uvos | yeah | 23:17 |
| uvos | (but it just loads the _MESA blobs | 23:18 |
| uvos | ) | 23:18 |
| uvos | its just a wrapper | 23:18 |
| uvos | but this is enough | 23:18 |
| freemangordon | right | 23:18 |
| freemangordon | but, where is the source code? | 23:18 |
| uvos | https://github.com/IMbackK/mesa/tree/mesa-pvr-meamo | 23:18 |
| freemangordon | oh, this is the whole mesa | 23:19 |
| uvos | yeah the prv driver is in tree there | 23:19 |
| uvos | it just loads libglslcompiler.so and libGLESvX_PVR_MESA | 23:20 |
| uvos | no other blobs needed | 23:20 |
| uvos | (well you need extra stuff for pvrsrvinit | 23:20 |
| uvos | ) | 23:21 |
| freemangordon | right | 23:21 |
| uvos | anyhow it has added issues | 23:21 |
| uvos | i use this for wayland | 23:21 |
| uvos | and for some reason glamor bails early because it dosent find a texture format it likes | 23:22 |
| uvos | and glmark also dosent work | 23:22 |
| freemangordon | hmm, weird | 23:22 |
| uvos | weston/ sway and kmscube work fine | 23:22 |
| uvos | so thats why i was trying to swtich | 23:22 |
| uvos | but figureing iout why it dosent work might be better anyways | 23:23 |
| uvos | since you can compile egl with x11 support using this | 23:23 |
| freemangordon | gbm should work | 23:23 |
| freemangordon | I am not sure you can, because x11 support was not compiled in the blobs | 23:24 |
| uvos | well you can to the point that egl advertises it | 23:24 |
| uvos | but no idea if it works | 23:24 |
| uvos | since xorg dosent start at all | 23:24 |
| freemangordon | it will not | 23:24 |
| freemangordon | but anyway, it is too late here already and I am not sure I am of any use now :) | 23:25 |
| uvos | ok | 23:25 |
| freemangordon | so going to have some sleep | 23:25 |
| uvos | but where dose the x11 platform go into the blobs | 23:25 |
| freemangordon | in dri support | 23:25 |
| uvos | since the compiled out part you investigated long ago was in egl | 23:25 |
| uvos | ok | 23:25 |
| uvos | so pvr_dri.so contains/needs support? | 23:26 |
| freemangordon | dont; remember the details now, but every windowing system (WL,gbm, x11) has support in the blobs. x11 was compiled out | 23:26 |
| uvos | yeah but that was (at least what you showed in re) in libEGL | 23:27 |
| freemangordon | not pvr_dri | 23:27 |
| uvos | thats no longer a blob | 23:27 |
| freemangordon | ok, lemme check | 23:27 |
| freemangordon | uvos: IIRC, in libgbm | 23:28 |
| uvos | also not a blob | 23:28 |
| freemangordon | uvos: libEGL | 23:33 |
| uvos | right | 23:34 |
| uvos | so theres a chance it would work | 23:34 |
| freemangordon | no, lemme show you the code | 23:35 |
| freemangordon | (decompiled) | 23:35 |
| freemangordon | uvos: see PM | 23:38 |
| freemangordon | but basically: | 23:39 |
| freemangordon | if (WL) then plat = 2 | 23:39 |
| freemangordon | else if (GBM) then plat = 1 | 23:39 |
| freemangordon | else plat = 1 | 23:39 |
| freemangordon | so, only GBM and wayland | 23:39 |
| freemangordon | the same is stated in release notes | 23:39 |
| uvos | (note for others): the function in question is implemented in foss mesa code in the chomos patches route | 23:44 |
| uvos | we dont know however if this means anything | 23:44 |
| uvos | anyhow geting glamor to work for 2d accel on pure pvr blobs first makes sense | 23:45 |
| uvos | since then we dont have to contend with the additional buggyness of chomeos mesa | 23:45 |
| uvos | we can switch later | 23:45 |
| freemangordon | uvos: h-d is build, night! | 23:52 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!