| mighty17[m] | <uvos> "mighty17: wrt what works and..." <- Still the same, just fixed accl and added vibrator, display/bl issue still exist, and I don't know how to do audio | 05:13 |
|---|---|---|
| freemangordon | ok, mistery around "Xorg: ../../../../include/privates.h:121: dixGetPrivateAddr: Assertion `key->initialized' failed." revealed | 07:21 |
| freemangordon | EXA has to be initialized on every ScreenInit | 07:21 |
| Wizzup | ah | 07:33 |
| Wizzup | nice find | 07:33 |
| freemangordon | eah, | 07:42 |
| freemangordon | yah | 07:42 |
| freemangordon | aah | 07:43 |
| freemangordon | *YEAH* | 07:43 |
| Wizzup | ? :D | 07:43 |
| freemangordon | still having my first coffee, typos | 07:43 |
| Wizzup | oh that was a frustrated correction rather than a scream in extasy | 07:43 |
| freemangordon | yeah | 07:43 |
| freemangordon | so, now h-d starts and if rotated to portrait with xrandr is visible/working | 07:44 |
| freemangordon | on d4 that is | 07:44 |
| freemangordon | however, in landscape there are some DRI errors | 07:44 |
| freemangordon | "PVRDRIBufferCreateFromNames: Failed to create plane from name" | 07:45 |
| freemangordon | but anyways, I will drop omap BOs in favor of gbm BOs | 07:46 |
| Wizzup | right | 07:46 |
| Wizzup | it'll be really cool to have this working | 07:46 |
| freemangordon | seems nobody uses kernel to rotate, even modesetting | 07:46 |
| freemangordon | but, IIUC omapdrm supports TILER framebuffer rotation | 07:47 |
| freemangordon | we''ll need VRFB as well | 07:47 |
| freemangordon | but here it becomes tricky, as there are 12 VRFB contexts max | 07:47 |
| freemangordon | so, I am not sure what is the correct time for attaching VRFB to FB | 07:48 |
| freemangordon | maybe only when rotation is requested | 07:49 |
| Wizzup | uvos: I see /dev/input/event7:Mapphone Audio Headphones - but I don't get plug events on it it seems | 07:49 |
| freemangordon | otherwise we may run out of contexts very quickly | 07:50 |
| Wizzup | freemangordon: hm, is this for a while fb or what? | 07:50 |
| Wizzup | whole* | 07:50 |
| freemangordon | also, it seems there is an issue with the rotation - IIUC, somehow PVR should see the rotated address | 07:50 |
| freemangordon | yes, the whole FB gets rotated | 07:51 |
| Wizzup | uvos: oh but pulse does pick it up | 07:51 |
| freemangordon | but, this makes sense | 07:51 |
| freemangordon | unless I don;t understand the question | 07:51 |
| Wizzup | freemangordon: well if we have 12, how many full framebuffers in rotation do we need active? | 07:51 |
| Wizzup | but really I'm just asking randomly | 07:51 |
| freemangordon | 1, but we don;t know in advance which exactly one ;) | 07:52 |
| Wizzup | hm, ok, I don't know much about vrfb | 07:52 |
| freemangordon | it is simple | 07:52 |
| freemangordon | it basically provides you with for addresses to access one and the same memory block | 07:53 |
| freemangordon | s/for/four | 07:53 |
| freemangordon | for 0/90/270/360 degress rotation | 07:53 |
| freemangordon | *degrees | 07:53 |
| freemangordon | look into trm, it is well explained | 07:54 |
| Wizzup | ok | 07:54 |
| freemangordon | the point is that the resource is limited to 12 contexts (context defines image memory, size and rotation) | 07:55 |
| freemangordon | but, I don;t know how is that supposed to work in terms of PVR driver trying to access that memory | 07:56 |
| freemangordon | because PVR shall write to the 'rotated' range | 07:57 |
| freemangordon | oh, wait, PVR renders to another bo | 07:58 |
| freemangordon | which we are copying to the framebuffer bo | 07:58 |
| freemangordon | hmm, hmm, that must be it | 07:58 |
| tmlind | freemangordon: sounds like that's the part i was wondering about for a long time, where does the copying happen? | 08:00 |
| freemangordon | which driver? | 08:00 |
| tmlind | pvr bo copy to framebuffer bo | 08:00 |
| freemangordon | in modesetting, glamor does it | 08:01 |
| tmlind | Wizzup: sounds like d4 should be available used by the truck pellet by this time, maybe try contacting some electronics recycling warehouses in the usa? | 08:01 |
| freemangordon | by wrapping PVR bo into KHRImage, and then to textture | 08:01 |
| freemangordon | and then it renders that texture to FB bo FBO | 08:02 |
| freemangordon | FBO is GL FBO | 08:02 |
| freemangordon | do you parse or I shall rephrase? | 08:02 |
| tmlind | well so are you saying also wayland must copy pvr bo to fb bo at some point? | 08:02 |
| freemangordon | yes | 08:02 |
| tmlind | ok so not done in the kernel | 08:03 |
| freemangordon | no | 08:03 |
| tmlind | that means likely the d4 artifacts are likely a missing flush on the pvr side before the bo gets copied to the fb bo | 08:03 |
| freemangordon | but! on fullscreen there should be no copy | 08:04 |
| freemangordon | PRESENT should just switch framebuffers on vblank | 08:04 |
| freemangordon | tmlind: I don;t think we can avoid the copy in non-fulscreen | 08:05 |
| tmlind | so what about running weston-simple-dmabuf-egl, where does that bo get copied? | 08:06 |
| tmlind | ok, just trying to understand how it works | 08:06 |
| freemangordon | what is weston-simple-dmabuf-egl? | 08:06 |
| freemangordon | tmlind: lets speck in terms of xorg, I don;t know what WL stuff does | 08:07 |
| freemangordon | though it should be similar/same | 08:07 |
| freemangordon | so, with modesetting: we have one scanout framebuffer, lets call it 'primary bo' | 08:07 |
| tmlind | freemangordon: that's the weston test app that fails like wlroots if trying to use the default render node | 08:08 |
| freemangordon | all the 2d rendering happens on 2d textures (which are basically offscreen pixmaps) which then glamor renders to that primary bo using GL | 08:09 |
| tmlind | mighty17[m]: sorry not really familiar with the audio stuff, just try to recycle and patch what's already there | 08:09 |
| tmlind | freemangordon: ok | 08:11 |
| freemangordon | for 3D - it is rendered to another bos (PVR GL GBM backed surface provides up to 3 buffers (bos) for double-buffering) | 08:11 |
| freemangordon | then the freshly rendered BO is being 'finished' by calling gbm_surface_lock_front_buffer (EGLSwapBuffers or similar does that, somewhere in MESA) | 08:12 |
| freemangordon | then this BO is being send to xserver by using the PRESENT extension | 08:13 |
| freemangordon | "being send" is simply passing dma_buf fd | 08:13 |
| tmlind | freemangordon: if you have some names for the pvr kernel module functions that get called around the bo copy to fb bo, i can try to debug the artifacts issue | 08:13 |
| freemangordon | no, this happens in userspace | 08:14 |
| freemangordon | in xorg/whatever userspace driver | 08:14 |
| tmlind | right but the flushing ioctl is still needed to scan out the pvr bo and that happens in kernel module? | 08:14 |
| freemangordon | I guess this is needed because of SGX MMU | 08:15 |
| freemangordon | in order SGX to be able to render to the memory | 08:15 |
| tmlind | sounds like we're now missing dma_sync_single somewhere in the pvr kernel driver after pvr userspace is done rendering to the pvr bo | 08:16 |
| freemangordon | you need to set-up its MMU, because we have no dedicated VRAM | 08:16 |
| tmlind | yup | 08:16 |
| freemangordon | tmlind: actually I think there is no "pvr bo" and "omapdrm bo" | 08:17 |
| tmlind | the artifacts are visible also with hdmi with uvos' sgx clock slow trick, we just don't notice them so easily as the screen gets repainted at 60hz | 08:17 |
| freemangordon | all bos are allocated by omapdrm | 08:17 |
| freemangordon | or rather by DRM engine | 08:17 |
| tmlind | freemangordon: right yes that's what i understand also, but pvr just uses a separate bo | 08:17 |
| freemangordon | which calls back omapdrm dma_buf callbacks | 08:17 |
| freemangordon | it can;t be separate, because FD is valid for all the kernel | 08:18 |
| freemangordon | also, define "separate | 08:18 |
| freemangordon | " | 08:18 |
| tmlind | hmm so maybe the missing flush is still somewhere in omapdrm, note that the pvr driver does it's own dma sync/invalidate calls | 08:18 |
| freemangordon | yes, but it does that from the SGX POV, iiuc | 08:19 |
| tmlind | yeah seems to mostly invalidate for sgx | 08:19 |
| freemangordon | it flushes what has been cached in SGX caches, no? | 08:19 |
| tmlind | not that i see | 08:19 |
| freemangordon | ah | 08:19 |
| tmlind | maybe that's the missing part | 08:20 |
| tmlind | i'm only seeing pvr_invalidate_range called sometimes | 08:20 |
| freemangordon | ok, seems I am missing the theory there | 08:21 |
| tmlind | me too | 08:21 |
| freemangordon | the point is: | 08:21 |
| freemangordon | we use WC memory for framebuffers, right? | 08:21 |
| tmlind | yeah | 08:21 |
| freemangordon | but, where the cache itself lives? | 08:21 |
| freemangordon | in DRAM controller? | 08:22 |
| freemangordon | I'll assume that | 08:22 |
| tmlind | well it's write-combine, i guess we could run some tests on non-cached too | 08:22 |
| freemangordon | noo, that'd run the performance even more | 08:23 |
| freemangordon | *ruin | 08:23 |
| tmlind | right but might be interesting to see for debugging if the artifacts go away | 08:23 |
| freemangordon | oh, it is write-combine, but the cached data stays in cache (so DSS reads stale data), until a flush happens | 08:24 |
| freemangordon | is that correct? | 08:24 |
| tmlind | if it works with uncached, then it rules out the missing flush for the write-combine buffer | 08:24 |
| tmlind | i suspect with the artifacts we get the pvr bo copy to fb bo before the pvr bo has been flushed out | 08:25 |
| tmlind | not easily visible at higher rates or on hdmi as the next frame already might be good | 08:25 |
| freemangordon | I need to re-read again my books on how WC works in terms of multiple devices accessing the memory bus | 08:25 |
| freemangordon | tmlind: agreed | 08:25 |
| freemangordon | but, there are fences, which looks to be used | 08:25 |
| tmlind | the reason sgx rate increase helps is the pvr bo is done earlier and more likely ready when pvr bo gets copied to the fb bo | 08:26 |
| freemangordon | mhm | 08:26 |
| freemangordon | sounds sane | 08:26 |
| freemangordon | tmlind: but, this is for 2d only | 08:27 |
| tmlind | is there some difference in the ioctls to trap when the userspace copies pvr bo to kernel bo? | 08:27 |
| tmlind | to add a dump_stack() call | 08:27 |
| freemangordon | tmlind: this is GL texture copy through shader | 08:27 |
| freemangordon | in terms of glamor that is | 08:28 |
| tmlind | hmm a stack trace would likely only show the ioctl to the call trace though, not what happens in the pvr driver earlier | 08:28 |
| freemangordon | tmlind: you can easily test by putting glFlush() | 08:28 |
| tmlind | what's the kernel ioctl that translates to? | 08:28 |
| tmlind | eventually | 08:28 |
| freemangordon | and setting fush behaviour to 2 in powervr.ini | 08:29 |
| freemangordon | oh, it is far from being that simple | 08:29 |
| freemangordon | (ioctl) | 08:29 |
| freemangordon | but, all this happens in the blobs, so not really sure how it's done | 08:29 |
| tmlind | ok, probably some pvr custom ioctl | 08:30 |
| freemangordon | I suspect they call blit on SGX mmu handles | 08:30 |
| freemangordon | BTW, every gbm bo can be kind of mmaped into SGX device address space | 08:31 |
| freemangordon | and you get a 'handle' to that | 08:31 |
| freemangordon | and then you can pass those handles to SGX, for various rendering ops | 08:31 |
| freemangordon | I suspect clsed blobs to the same/similar | 08:31 |
| freemangordon | ther is PVRSRVMapDmaBuf / PVRSRVUnmapDmaBuf that I was able to make working | 08:32 |
| freemangordon | tmlind: but again, to know the rendering is finished, one must call some "waitforopstocompete" or somesuch finction from the blobs | 08:33 |
| freemangordon | which, IIUC, reads some memory address that is visible by both SGX and CPU | 08:34 |
| freemangordon | non-cached memory I guess | 08:34 |
| tmlind | ok | 08:35 |
| freemangordon | tmlind: could you try to get tomi to help somehow for VRFB? | 08:35 |
| tmlind | freemangordon: probably best that you just send an email to the related mailing lists | 08:36 |
| Wizzup | maybe we should get the mesa and other stuff packaged for him so that it's perhaps easier to test/debug | 08:36 |
| freemangordon | I will take on the task to port VRFB to omapdrm, but I need some hints | 08:36 |
| tmlind | i doubt that tomi has much any cycles beyond dealing with current socs | 08:36 |
| tmlind | yeah tomi might have some good pointers | 08:37 |
| freemangordon | sure, that's why 'hints' :) | 08:37 |
| freemangordon | like, when is the best time to allocate VRFB context | 08:37 |
| tmlind | yeah worth trying to send an email | 08:37 |
| freemangordon | ok, need to pack, ttyl (next week) guys | 08:38 |
| tmlind | later enjoy your vacation :) | 08:39 |
| Wizzup | hey looks like pstore gets autologged to /var/log/pstore/* | 09:23 |
| Wizzup | I think that happens on reboot: https://pastebin.com/raw/gdwRaq0R | 09:25 |
| tmlind | oh interesting, that means the uart was not clocked when that happened | 09:30 |
| mighty17[m] | <tmlind> "mighty17: sorry not really..." <- yikes, does noone know about audio? it is very confusing :P for now i'll try usb-otg and pvr egl issues | 09:36 |
| mighty17[m] | `Cannot read pixels: missing GL_EXT_read_format_bgra extension` | 09:42 |
| uvos | Wizzup: the evdev interface works | 09:50 |
| Wizzup | ok, but not on the -devel 5.11 kernel | 09:52 |
| Wizzup | I think | 09:52 |
| uvos | no :P | 09:52 |
| uvos | Wizzup: its just that plug detection only works when the cpcap audio device has been used in some way recently, ie your playing something, the modem is playing something or pa has a stream active | 09:52 |
| uvos | this is a power managment thing in cpcap | 09:52 |
| Wizzup | well pa picks it up regardless I think | 09:52 |
| uvos | that i dont fully understand yet | 09:52 |
| uvos | no | 09:52 |
| Wizzup | hmm | 09:52 |
| uvos | just have to figure out what enable register for what device in cpcap ends up also enabling plug detection | 09:53 |
| uvos | but it works in practice rn anyhow because as soon as you play something it kicks in and the device detects the hp | 09:53 |
| uvos | or if you open pavucontrol | 09:54 |
| Wizzup | ah, yeah, ok | 09:54 |
| uvos | i think thats how its supposed to be used acctually and its a pm optimiziation. ofc for mainline kernel we have to work around it and make it report even when there is no audio in use. | 09:55 |
| uvos | btw | 09:56 |
| uvos | you broke osso-xterm | 09:56 |
| uvos | since you rebuilt it and now .launch is an so | 09:56 |
| Wizzup | how? | 09:56 |
| uvos | x-terminal-emulator is broken | 09:56 |
| mighty17[m] | <mighty17[m]> "https://github.com/torvalds/..." <- tmlind: | 09:57 |
| Wizzup | ah... | 09:57 |
| uvos | and you cant link x-terminal-emulator to osso-xterm either | 09:58 |
| uvos | then maemo invoker dosent find the .launch | 09:58 |
| Wizzup | I'll debug a bit later today | 09:59 |
| uvos | thank you ;) | 10:00 |
| uvos | ncmpcpp not working is annoying :P | 10:01 |
| Wizzup | tmlind: btw I asked someone in the us if he has some ideas about recycle places because I don't really know much | 10:22 |
| Wizzup | uvos: so I guess it's e93e26432d5c3b3a697c050e4021392717dfd5af that broke it | 10:22 |
| Wizzup | oh it could be my moderinisation maybe | 10:23 |
| tmlind | Wizzup: i used to have friends at a place called "hmr usa" but seems that place is no longer around | 10:25 |
| uvos | Wizzup: yes | 10:26 |
| uvos | Wizzup: that commit is the issue | 10:26 |
| uvos | since it causes .launch to be an so | 10:27 |
| uvos | the real problem, why we where launching the .launch directly was that maemo launcher breaks on symbolic links | 10:27 |
| Wizzup | tmlind: ok, if you have any other ideas, please let me know | 10:28 |
| Wizzup | uvos: https://github.com/maemo-leste/bugtracker/issues/484 | 10:28 |
| Wizzup | I see | 10:28 |
| uvos | .launch being an so is needed for newer glibc | 10:28 |
| uvos | glibc broke it and mameo launcher dlopening a normal binary was a terrible hack in the first plae. | 10:29 |
| uvos | (well launcher is a terrible hack either way but i degress :P) | 10:29 |
| tmlind | Wizzup: i'll send an email with you in cc, let's see what we find | 10:30 |
| Wizzup | tmlind: ty :) | 10:30 |
| Wizzup | I got so used to using my d4 I was trying to insert the hp in the wrong side on my n900 | 10:45 |
| Wizzup | good sign | 10:45 |
| uvos | heh | 10:47 |
| tmlind | Wizzup: ok mail sent to my old hmr usa friend, let's attempt to preserve as many as we can from recycling | 10:49 |
| Wizzup | tmlind: agreed! | 10:49 |
| Wizzup | thanks for that | 10:50 |
| tmlind | np | 10:50 |
| Wizzup | we can probably use some of the funding for it too | 10:50 |
| tmlind | great | 10:50 |
| tmlind | and if we manage to source few pellets full of them, we can probably get help from other non profit orgs for distributing to folks in the 3rd world countries too for reuse | 10:51 |
| Wizzup | yeah, that'd be great | 10:51 |
| tmlind | still few years of usage easily left even in gsm mode | 10:52 |
| Wizzup | we could try for the droid 3 too if those are still in circulation too, since they might even work in the us | 10:52 |
| tmlind | good idea, maybe reply to that mail | 10:52 |
| Wizzup | (with sigmakey unlock) | 10:52 |
| uvos | i mean you could look for d3s outside the us too | 10:52 |
| uvos | m3s, whatever | 10:53 |
| tmlind | yeah sure | 10:53 |
| tmlind | let's see what we can find, then maybe set up a new webpage for sourcing usable phones | 10:53 |
| Wizzup | uvos: I found it extremely hard to find any at all in europe | 10:53 |
| Wizzup | tmlind: yeah | 10:53 |
| uvos | Wizzup: they wernt sold in europe | 10:54 |
| tmlind | you'd assume it would be easy to find sponsors for something like that, maybe even verizon could be interested to sponsor that kind of reuse | 10:54 |
| uvos | they where sold in south america and china + south asia | 10:54 |
| tmlind | ok | 10:54 |
| uvos | at least in volume | 10:54 |
| uvos | i think you could order one from moto europe directly at some point | 10:54 |
| Wizzup | do we know anyone who works at verizon? | 10:55 |
| tmlind | don't think so, but these recycling folks probably do | 10:55 |
| tmlind | recycling must be a huge issue.. so shipping them to reuse outside your market would be good publicity stunt | 10:56 |
| Wizzup | *nod* | 10:58 |
| parazyd | That's brilliant | 10:59 |
| Wizzup | I also found this https://smartphonerecycling.com/ | 11:02 |
| tmlind | worth emailing for sure | 11:12 |
| mighty17[m] | tmlind: https://github.com/tmlind/wlroots/commit/04491889240bbadb693aa37036dc55835118b2cc the desc of this commit is bit confusing, does it imply that pvr has IMG_read_format as a replacement for EXT_read_format_bgra ? | 11:36 |
| tmlind | yeah so it seems | 11:39 |
| mighty17[m] | wait, what?! | 11:42 |
| mighty17[m] | https://docs.imgtec.com/Architecture_Guides/Supported_Extensions_OpenGL_ES_EGL/topics/d0e2505.html so series5 has some other thing, series6 got it properly? | 11:42 |
| mighty17[m] | so we can probably replace `EXT_read_format_bgra` with `IMG_read_format` in wlroots, and then we're only left with 1 missing extension? :D | 11:44 |
| l_bratch | awesome October update post :) | 12:16 |
| Wizzup | l_bratch: cheers | 12:17 |
| Wizzup | tmlind: I am not sure what you meant regarding part numbers, do you mean spare parts? | 12:42 |
| Wizzup | hrm: | 12:52 |
| Wizzup | https://dpaste.com/GZT9YUGWA.txt | 12:53 |
| Wizzup | uvos: I added this to /etc/default/ofono: | 12:55 |
| Wizzup | DAEMON_OPTS="-d "*,*/*,*/*/*"" | 12:55 |
| Wizzup | and /etc/rsyslog.d/daemons.conf: | 12:55 |
| Wizzup | if $programname == 'ofonod' then /var/log/test/ofonod.log | 12:55 |
| Wizzup | & stop | 12:55 |
| Wizzup | (did it for some others as well) | 12:55 |
| Wizzup | might help making debugging easier | 12:55 |
| * Wizzup afk | 12:55 | |
| mighty17[m] | tmlind: also `GL_EXT_read_format_bgra` working for you in wlroots (i assume you use 0.14) | 13:31 |
| uvos | mighty17[m]: thats just an input driver | 13:58 |
| uvos | mighty17[m]: it exposes the powerbutton on pmic gpio to userspace on evdev | 13:58 |
| mighty17[m] | Ah I wonder why not in Mainline :P | 16:08 |
| Wizzup | https://packages.debian.org/sid/qtbase5-gles-dev not in buster :/ | 17:02 |
| Wizzup | ( https://packages.debian.org/source/sid/qtbase-opensource-src-gles ) | 17:03 |
| Wizzup | uvos: regarding osso-xterm, osso-xterm $(which ncmpcpp) seems to work | 17:26 |
| Wizzup | from console | 17:26 |
| Wizzup | oh right it's the x-terminal-emulator thing | 17:27 |
| Wizzup | uvos: ok so maemo invoker and maemo launcher just appends .launch blindly and then tries $PATH | 18:05 |
| uvos | Wizzup: so it looks for x-terminal-emulator.path? | 18:13 |
| uvos | Wizzup: *so it looks for x-terminal-emulator.launch? | 18:13 |
| Wizzup | uvos: so first of all the symlink will have to change to osso-xterm from osso-xterm.launch | 18:14 |
| Wizzup | but secondly I need to change the code to do this: | 18:14 |
| uvos | yeah sure | 18:14 |
| Wizzup | * First resolve in PATH | 18:14 |
| Wizzup | * Then resolve symlink(s) | 18:14 |
| Wizzup | * Then add launch | 18:14 |
| Wizzup | * Then run | 18:14 |
| Wizzup | what it does right now is: | 18:14 |
| uvos | yeah | 18:14 |
| Wizzup | * append .launch if not absolute path | 18:14 |
| Wizzup | * search in PATH | 18:14 |
| Wizzup | * run | 18:14 |
| uvos | ok | 18:15 |
| Wizzup | so it makes it x-terminal-emulator.launch | 18:15 |
| uvos | ok | 18:15 |
| Wizzup | I'll fix it, I don't think this can break things even though it'll work slightly differently | 18:15 |
| Wizzup | we'll see | 18:15 |
| uvos | if you cant do it rn, maybe drop maemo-launcher support from osso-xterm build untill it works | 18:15 |
| uvos | since it breaks all the terminal=true applications | 18:15 |
| Wizzup | no, I will do it today or tomorrow | 18:16 |
| uvos | ok | 18:16 |
| Wizzup | it's been a long day though :) | 18:16 |
| uvos | no worrys | 18:16 |
| uvos | just if you want to do something else first | 18:16 |
| Wizzup | nah I'll do this first | 18:16 |
| uvos | Wizzup: so what do you want to do about the charge-mode problem? | 18:26 |
| Wizzup | I was going to test it this morning but forgot | 18:26 |
| uvos | ok | 18:26 |
| uvos | we need to either enable charge-mode | 18:27 |
| uvos | or disable battery guard i guess | 18:27 |
| uvos | but i dont like the latter because the battery can end up <3v | 18:27 |
| uvos | which is bad | 18:27 |
| Wizzup | does charge mode auto detect if it needs to charge? probably not right? | 18:27 |
| uvos | Wizzup: not sure what you mean | 18:28 |
| uvos | the device ends up in the charge-mode runlevel if it boots with the usb plugged in | 18:28 |
| Wizzup | what does boot.cfg look like in your proposed scenario | 18:28 |
| Wizzup | another entry with softlevel=charge-mode? | 18:28 |
| uvos | Wizzup: no | 18:28 |
| Wizzup | ok | 18:28 |
| uvos | the signle entry gets softlevel=charge-mode | 18:29 |
| uvos | the charging sdl then runs and checks machine state | 18:29 |
| Wizzup | ok | 18:29 |
| uvos | and boots another runlevel or shows the battery symbol depending on the conition it finds | 18:29 |
| Wizzup | let me try | 18:29 |
| * Wizzup reboots | 18:29 | |
| uvos | if usb is not plugged it boots to default | 18:30 |
| uvos | if usb is plugged but the battery is full it powers off | 18:30 |
| uvos | if the power button is pressed it boots default | 18:30 |
| Wizzup | 18:30 < uvos> if usb is plugged but the battery is full it powers off | 18:30 |
| uvos | if an alarm fires it boots default | 18:30 |
| Wizzup | I have to question this I think | 18:30 |
| uvos | if the usb cable is removed it powers off | 18:30 |
| Wizzup | aha | 18:31 |
| Wizzup | well it booted to charge mode alright | 18:31 |
| uvos | right now you can unplugg to power of | 18:31 |
| Wizzup | battery shows low red, but it was full in h-d | 18:31 |
| Wizzup | does it turn off the screen eventually? | 18:31 |
| uvos | it tries to | 18:31 |
| uvos | but driectfb cant | 18:31 |
| uvos | with the drm sdl backend it works | 18:31 |
| Wizzup | so it'll maybe draw more power than it receives | 18:31 |
| uvos | no | 18:32 |
| Wizzup | (I just tried on d4) | 18:32 |
| uvos | it charges | 18:32 |
| uvos | but yeah its slow | 18:32 |
| uvos | (this will start working with ddk1.17 for free) | 18:32 |
| Wizzup | ok, so it's known not to close screen on d4 | 18:32 |
| Wizzup | I thought that already drm | 18:32 |
| Wizzup | s/close/turn off/ | 18:33 |
| uvos | no it runs on driectfb | 18:33 |
| uvos | becasue drm is broken on ddk1.9 | 18:33 |
| Wizzup | hah I think because I used charge-mode ofono for once recognizes the sim properly | 18:33 |
| uvos | heh | 18:33 |
| uvos | beacuse it delays boot i gues | 18:33 |
| Wizzup | yes | 18:33 |
| uvos | the fbdev device on d4 is also buggt | 18:34 |
| uvos | those lines should not be there | 18:34 |
| uvos | thats a known issue | 18:34 |
| uvos | (also on the kernel m-l) | 18:34 |
| uvos | btw | 18:34 |
| Wizzup | ok | 18:35 |
| uvos | is a chache coherency issue with omapdrmfb | 18:35 |
| kona_ | i did something unexpectedly inauspicious: i updated my n900 maemo-leste and now the ui acts strange in the following ways: apps don't launch, and if i launch them from ssh the windows show up but i can't switch between them (it always goes back to showing the home screen when i select one.) | 18:45 |
| buZz | thats a interesting bug | 18:45 |
| kona | it's unexpected, for sure. | 18:46 |
| kona | Seems like maybe time to re-image :) | 18:46 |
| uvos | hmm wierd | 18:46 |
| uvos | are you on devel or stable? | 18:47 |
| uvos | can you click stuff in the apps you launch? | 18:48 |
| uvos | Wizzup: the issue with xorg reporting the wrong display size on n900 breaking hildons setting of the input transformation matrix was fixed right? | 18:49 |
| kona | uvos: it's sort of acting like the screen needs re-cal | 18:51 |
| kona | can't click in the apps | 18:52 |
| uvos | kona: could you paste xinput list-props $TOCHSCREENID? | 18:52 |
| kona | standby | 18:52 |
| kona | uvos: os-release https://pastebin.com/qVSWXvXM | 18:53 |
| uvos | thats non interesting i know your running leste :P | 18:54 |
| kona | not sure if devel or stable? | 18:54 |
| uvos | dosent say there | 18:55 |
| uvos | thats in cat /etc/apt/sources.list | 18:55 |
| uvos | im also more instested in "xinput list-props $TOCHSCREENID" | 18:55 |
| uvos | if you have a line with "beowulf-devel" in /etc/apt/sources.list your on devel | 18:56 |
| kona | https://pastebin.com/Dn51Pzpw | 18:56 |
| kona | I don't see -devel there. | 18:56 |
| uvos | ok so your on stable | 18:56 |
| uvos | now xinput | 18:56 |
| kona | now for the dumber question: $TOUCHSCREENID is not set, should this be the X Display or? | 18:57 |
| uvos | kona: run xinput with no paramters | 18:57 |
| uvos | under Virtual core pointer | 18:57 |
| uvos | you have a device other than the XTEST pointer | 18:57 |
| uvos | that is the touchscreen | 18:57 |
| uvos | it has an id | 18:57 |
| kona | TSC2005 touchscreen id=8 [slave pointer (2)] | 18:57 |
| uvos | great | 18:57 |
| kona | so, 8 | 18:57 |
| uvos | so its 8 | 18:57 |
| uvos | yeah | 18:57 |
| kona | https://pastebin.com/Lmii8pKK | 18:58 |
| uvos | crap | 18:58 |
| kona | crap? | 18:59 |
| uvos | yeah we messed up | 18:59 |
| uvos | sec | 18:59 |
| uvos | sorry | 18:59 |
| kona | no worries. i figured it was me. | 18:59 |
| kona | :) | 18:59 |
| uvos | Wizzup: parazyd: we broke the n900 by accident by not fixing xf86-video-pvrsgx but updating hildon-desktop for stable :( | 19:00 |
| uvos | kona: xinput set-prop 8 --type=float "Coordinate Transformation Matrix" 1 0 0 0 1 0 0 0 1 | 19:01 |
| uvos | should fix it temporarly | 19:01 |
| kona | uvos: do i need to restart anything after that command? | 19:04 |
| uvos | kona: no | 19:04 |
| Wizzup | uvos: hm | 19:05 |
| uvos | you where working on pvrsgx beacuse xinput map-to-output was broken | 19:05 |
| uvos | because n900 reports a display size of 0 | 19:05 |
| uvos | i totaly forgot about that | 19:06 |
| uvos | and now stable is broken on n900 | 19:06 |
| Wizzup | yeah | 19:07 |
| Wizzup | well, we could do a quick fix and not apply it on n900 | 19:08 |
| uvos | sec ill add a check for sanity to the matrix to h-d | 19:08 |
| uvos | then we just have to rush that patch to devel | 19:08 |
| Wizzup | and then to stable | 19:08 |
| uvos | yeah | 19:09 |
| kona | i don't think that command quite worked. | 19:12 |
| kona | https://pastebin.com/G2aG54Fy <-- new output from list-props | 19:13 |
| kona | seems like the same as before? | 19:14 |
| uvos | h-d reapplies the matrix when the display turns on i think | 19:15 |
| uvos | have the display on | 19:15 |
| uvos | run xinput set-prop 8 --type=float "Coordinate Transformation Matrix" 1 0 0 0 1 0 0 0 1 | 19:15 |
| uvos | and try using the device immidatly with no delay | 19:15 |
| uvos | should work for at least a short while | 19:15 |
| kona | that seems to have worked. | 19:15 |
| kona | thanks! | 19:19 |
| lel | IMbackK opened a pull request: https://github.com/maemo-leste/hildon-desktop/pull/16 (hd-xinput: sanity check matrix before applying it) | 19:23 |
| uvos | Wizzup: here comes a fix with all haste | 19:23 |
| uvos | only tested to not interfear with d4, my n900 is empty | 19:23 |
| kona | uvos: as you indicated, the system seems to revert to the previous matrix after some time of screen inactivity. | 19:25 |
| uvos | yeah | 19:25 |
| uvos | kona: real fix should be incomeing real soon | 19:25 |
| kona | yay! | 19:26 |
| kona | i'm just glad that when you said "crap" it wasn't that my touchscreen is dead :) | 19:26 |
| lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/hildon-desktop/pull/16 (hd-xinput: sanity check matrix before applying it) | 19:28 |
| Wizzup | uvos: shall we just go straight to stable | 19:28 |
| Wizzup | I don't see the point of -devel | 19:29 |
| uvos | i do see the point of testing it on a n900 | 19:29 |
| uvos | for one second | 19:29 |
| Wizzup | ok | 19:29 |
| uvos | altho it not working is qutie unlikely | 19:29 |
| uvos | maybe kona wants to test it :P | 19:29 |
| kona | sure, how do i test it? | 19:30 |
| Wizzup | building for -devel first then | 19:30 |
| uvos | add "deb https://maedevu.maemo.org/leste beowulf-devel main contrib non-free n900" to /etc/apt/sources.list at the end | 19:30 |
| uvos | kona: ^^^ | 19:31 |
| uvos | and wait for my mark | 19:31 |
| * kona is standing by | 19:31 | |
| Wizzup | mark | 19:45 |
| uvos | kona: do a apt update and upgrade | 19:46 |
| kona | apt update is running | 19:46 |
| uvos | kona: should pull a new h-d | 19:46 |
| uvos | (hildon-desktop) | 19:46 |
| kona | hildon-desktop/testing 1:2.2.184+2m7 armhf [upgradable from: 1:2.2.183+2m7.1] | 19:47 |
| uvos | thats the ticket | 19:47 |
| kona | hildon-meta is being kept back, but i told it to proceed anyway | 19:48 |
| kona | upgrade finished, same behavior, but i'm not convinced that h-d restarted | 19:50 |
| uvos | kona: you have to reboot | 19:50 |
| kona | rebooting. | 19:50 |
| Wizzup | you could have done 'pkill hildon-desktop' | 19:53 |
| Wizzup | but yeah | 19:54 |
| Wizzup | (as root) | 19:54 |
| kona | years of running windows at work have desensitized me to reboots. | 19:54 |
| Wizzup | :) | 19:55 |
| kona | uvos: Wizzup: seems to work for me. | 19:55 |
| kona | do you want the list-props output to verify? | 19:55 |
| kona | Coordinate Transformation Matrix (156): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 | 19:56 |
| Wizzup | nah | 19:56 |
| kona | k | 19:56 |
| Wizzup | ty :p | 19:56 |
| Wizzup | building for beowulf now | 19:57 |
| lel | IMbackK closed an issue: https://github.com/maemo-leste/bugtracker/issues/375 (Qwebengine renders empty frame on Droid4) | 19:57 |
| kona | now i can manage my beowulf cluster from beowulf. | 20:01 |
| kona | or something :) | 20:01 |
| Wizzup | ;) | 20:01 |
| kona | I celebrated the restoration of the touchscreen to working order in -devel by replacing the screen protector my n900 came with, it was peeling up one side | 20:59 |
| Wizzup | :) | 20:59 |
| kona | I don't think I've ever been so successful applying a screen protector before... | 21:00 |
| kona | https://rootaction.net/owncloud/index.php/s/B4TKayoAsmMATtE | 21:02 |
| uvos | qt example webbrowser thats suprisingly feture full and polished http://uvos.xyz/maserati/screenshots/qtwebbrowser.png | 21:08 |
| uvos | also has own vkb http://uvos.xyz/maserati/screenshots/qtwebbrowser2.png | 21:09 |
| kona | Uvos: is that in the repo? | 21:40 |
| uvos | no | 21:40 |
| kona | I'll have to chase it down and build for n900 | 21:43 |
| uvos | it uses qml just opeing it pushes the d4 over 500mb memory usage | 21:43 |
| uvos | so really wont work on n900 | 21:44 |
| kona | sad | 21:45 |
| dsc_ | uvos: do you have a link to the code? is it this https://doc.qt.io/archives/qt-5.9/activeqt-activeqt-webbrowser-example.html ? | 21:49 |
| uvos | git clone https://code.qt.io/cgit/qt-apps/qtwebbrowser.git/ | 21:50 |
| dsc_ | using QWebEngineView via QtWidgets should be more performant, someone said "30mb memory usage on d4" today but I have yet to confirm that :P | 21:56 |
| Wizzup | dsc_: 30-40MB | 22:42 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
