| duflu | RAOF: Did you notice bug 1660017 ? | 06:40 |
|---|---|---|
| ubot5 | bug 1660017 in Mir "EDID does not change when hotplugging a monitor" [Medium,New] https://launchpad.net/bugs/1660017 | 06:40 |
| duflu | I know it's almost EOD | 06:40 |
| RAOF | Huh. | 06:42 |
| RAOF | I did not. | 06:42 |
| duflu | (assuming hotplugging does not crash the server, which still happens but I have not clearly described in any recent bug) | 06:46 |
| RAOF | I am confused. | 06:53 |
| RAOF | We're using the functions documented as doing a full hardware probe. | 06:54 |
| RAOF | ???? | 07:04 |
| RAOF | EOD | 07:04 |
| alan_g | duflu: as you've poked around Xmir, maybe you know the answer... I'm trying to use it in a snap, (where nothing is ever on the default path) and it can't find sxkbcomp. I can see it holds the format string "%s%sxkbcomp" -w %d %s -xkm "%s" -em1 %s -emp %s -eml %s "%s%s.xkm", but is there a way to set the first %s field? (A quick look at the code suggests it's a build-time constant, but I'm hoping I missed something.) | 09:43 |
| duflu | alan_g: Did you build Xmir or copy from archive? | 09:45 |
| alan_g | from archive | 09:46 |
| duflu | (The trick to avoid similar issues when building Xmir is to configure with --prefix=/usr) | 09:46 |
| alan_g | duflu: it needs to be (at runtime) %SNAP/usr | 09:48 |
| duflu | alan_g: No idea then sorry | 09:48 |
| duflu | Oh | 09:48 |
| alan_g | But I guess you've confirmed that it's set at build time | 09:48 |
| alan_g | thanks | 09:48 |
| duflu | alan_g: Maybe this is the same problem in reverse. You need to build Xmir with --prefix=<replacement for /usr> | 09:48 |
| alan_g | At build time we don't know %SNAP | 09:49 |
| duflu | Yep. Xorg code is a bit older than that | 09:49 |
| * duflu looks at the source | 09:51 | |
| duflu | alan_g: Looks easily configurable. The first %s is the bin dir and the second is forward or backslash | 09:53 |
| duflu | I could do that. | 09:53 |
| alan_g | ack, But it isn't a priority (ATM), and likely not the last blocker. | 09:55 |
| duflu | alan_g: Are you suggesting the first %s is empty or non-empty and wrong? | 09:56 |
| duflu | Looks like building with empty should work (and default to $PATH) | 09:57 |
| alan_g | No, the first % is /usr and is wrong in a snap | 09:57 |
| alan_g | it needs to be (at runtime) %SNAP/usr | 09:57 |
| duflu | alan_g: Yeah looks like the source is written to nicely handle NULL and search the path, but our builds are hardcoded | 09:57 |
| alan_g | I was hoping that I'd missed an env variable or similar (windows has winFixupPaths()). | 09:59 |
| duflu | alan_g: Sounds easy to test and fix. I'll just stop using the --prefix workaround and see what works then. Sadly there is no environment. It's popen'd with an optional hardcoded bin path | 09:59 |
| alan_g | that's what I thought. :( | 10:00 |
| duflu | It stumped me too. When I first looked at Xmir it didn't work because the default build uses /usr/local for it which is wrong on Ubuntu | 10:01 |
| duflu | I never changed any release build parms, just have a technique for building it in development. | 10:01 |
| duflu | alan_g: Tomorrow. Now; dinner | 10:02 |
| alan_g | duflu: Have a good one! | 10:02 |
| duflu | o/ | 10:02 |
| === hikiko is now known as hikiko|ln | ||
| alan_g | greyback: starting to think about D&D support. Where are the "drag start, drag move & drop events" initiated (a toolkit API mir_window... call?) handled (a server interface?) and delivered (a toolkit MirWindowEventCallback event?) | 11:51 |
| greyback | alan_g: to begin, have you seen this doc? https://docs.google.com/document/d/1IztlvbrJHmvLe3im1xe5WIKHkh4-SlBguokBCgXMgLo/edit# | 11:56 |
| alan_g | greyback: was skimming docs but lacking overview. That's the starting point? | 11:57 |
| greyback | alan_g: IMO yeah. It was roughly what we agreed on at the sprint in Montreal | 11:58 |
| alan_g | greyback: thanks, will read before bugging you again | 11:59 |
| greyback | alan_g: np | 11:59 |
| * alan_g wonders how to represent "list of drag surfaces + origins" | 12:06 | |
| === hikiko|ln is now known as hikiko | ||
| dandrader | alan_g, does a mir_buffer_stream_swap_buffers_sync ever time out? I'm debbuging a situation where I have an internal client (mirclient run in a thread) gets stuck in mir_buffer_stream_swap_buffers_sync() forever while because server is unable to drop buffers from it. that all happens when I'm trying to close that client. | 12:53 |
| alan_g | dandrader: no timeout AFAIK | 12:55 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| alan_g | greyback: quick one I see "A list of drag surfaces + origins" in one of the diagrams. Is this buffer stream(s) + hotspot(s)? Why is there a list? | 14:23 |
| greyback | alan_g: list because multiple items may be selected, and we thought it made sense to allow shell to decide how those items can be laid out | 14:24 |
| greyback | we've not had much design input until recently | 14:25 |
| greyback | alan_g: this is all I know: https://docs.google.com/presentation/d/1NEcPwodymSAjvsUGWlDx7ocDLhs41edkPGq_MsA_BdM/edit#slide=id.g19dd5d1a07_2_23 | 14:25 |
| greyback | alan_g: also note there is a process diagram in there, which differs to the one in the doc I gave you. The differences have yet to be figured out and clarified | 14:26 |
| greyback | I'm doing that right now actually | 14:26 |
| alan_g | ack | 14:28 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!