00:10giucam: FunkyBob: i don't think i follow
00:10giucam: can you make another test case?
00:34FunkyBob: giucam: yeah, ran out of time at work
04:08Uninstall: jekstrand: can you give me some advices about fullscreen-shell shell module?
04:09Uninstall: I'm trying to start weston using "weston --fullscreen --shell=fullscreen-shell.so "
04:09Uninstall: but what I get is just a black screen and nothing more
04:09Uninstall: and I cannot start any weston-terminal or nested weston inside it
05:26ManMower: Uninstall: does weston-terminal assert in line 4538 of window.c or similar?
08:01jekstrand: Uninstall: Yup, you get a black screen. The fullscreen shell is only for running a single app and you don't have one started yet.
08:02jekstrand: Uninstall: You need to open another terminal or VT, set the WAYLAND_DISPLAY env var manually, and then start Weston again. It should then connect to the fullscreen shell and off you go.
08:05ManMower: you need two instances of weston to use fullscreen shell?
08:06giucam: the parent and the child
08:06giucam: but i seemd t oremember there was a way to start the child automatically
08:06giucam: was i dreaming?
08:28rawoul: hardening: do you have a fix for the TLS issue you found yesterday ?
08:56efiop: hi! is there a way for a client to get all information about it's state to be able to set that information again later?
08:57giucam: efiop: clients know all the information they can know already
08:57efiop: you mean because they set it?
08:58daniels: efiop: exactly - if they set it and need to query it later, they have to cache it themselves - wayland itself does not provide any queries
08:58efiop: i'm rather talking about a situation, when i'm intersepting some process and dont know what actuall calls he was doing before
08:58daniels: efiop: it's almost impossible to do so without race conditions for the most part
08:58daniels: efiop: if you want to see which calls have been made, run the client with WAYLAND_DEBUG=client set in the environment
08:58daniels: efiop: this will dump _all_ protocol calls the client makes
08:59efiop: the problem is, i should not change client startup in any way
08:59efiop: generally =)
08:59efiop: ok, let me give you some more info about what i'm trying to accomplish
09:00efiop: i was asking similar questions about server last year
09:01efiop: there is a project called CRIU(checkpoint restore in userspace) and I would like to inplement support for dumping Wayland apps
09:01efiop: CRIU doesn't need to know anything about how the process was started or anything like that
09:02efiop: so setting WAYLAND_DEBUG is a bad option
09:02efiop: yet, sounds good =)
09:02efiop: is there a way to get all client info in general case, when i don't know nothing about what app was doing before?
09:04efiop: so there is not enough "getters"?
09:04giucam: if you don't like WAYLAND_DEBUG another option is to put middleman between the compositor and the clients, which sees everything that passes
09:04giucam: no getters at all
09:05efiop: so I can set window size, but can't get it?
09:05daniels: efiop: the problem is much more existential than that
09:05ManMower: write a valgrind theme.
09:06daniels: efiop: window contents are stored in wl_buffer objects. you can use dmabuf handles to create a wl_buffer, which means the content only really lives as long as the file descriptor. how do you reconstruct that after a reboot?
09:06daniels: efiop: there's a _lot_ you need to do to make this workable, and i can't see how it can be achieved in a totally transparent manner
09:07daniels: efiop: you'll ultimately need to add support to one or all of apps, compositor and perhaps even gpu driver
09:07efiop: daniels: file descriptor? It is the one that connected to socket? criu is able to recreate it
09:08giucam: a file descriptor being a handle to gpu memory, not for the socket
09:08daniels: efiop: ^
09:08efiop: so the best way to accomplish dump/restore of an app is to use WAYLAND_DEBUG or man in the middle?
09:08daniels: efiop: dmabuf is a way to get handles to existing buffers allocated by kernel subsystems (drm, v4l, etc) with a file descriptor
09:08daniels: efiop: so users can import buffers created by these subsystems as wayland buffers
09:08daniels: efiop: when the application restarts - how do you preserve the content of those buffers?
09:09ManMower: and the entirety of gpu state so the next buffer it renders is right
09:09daniels: efiop: you need _some_ knowledge _somewhere_ to a) dump the content of those buffers, and b) reconstruct those buffers on startup
09:09efiop: won't it just redraw itself?
09:09daniels: efiop: maybe, but maybe not
09:09daniels: efiop: for that we'd really need a method to tell clients 'hey oops, we just threw away this buffer's content, please repaint'
09:10daniels: efiop: which would require some knowledge of checkpoint/restart in the compositor
09:10efiop: could it be accomplished the same way fold works?
09:10daniels: efiop: apps using opengl also lean _extremely_ heavily in saved gpu state - they will burst into flames if you just restart
09:10daniels: efiop: i'm not familiar with fold
09:10ManMower: fold? the shell util that folds lines to 80 columns? :)
09:10efiop: i mean, like "minimize window"
09:11ManMower: the way to do this is to have the apps involved in the process somehow. some data serialization/storage framework.
09:11efiop: not fold, but minimize =)
09:11daniels: efiop: minimising a window doesn't mean the buffer contents disappear
09:12daniels: efiop: in wayland, buffers are separate from display. the client allocates buffers for storage, and then tells the compositor to display buffer id $n
09:12daniels: efiop: the presumption is that we never discard buffer contents, so we must always honour the request to display
09:12daniels: efiop: and then - how does the compositor _know_ that the contents of the buffer have gone? we need a way for the kernel to tell the compositor that the contents have disappeared
09:13efiop: so what is the way to get and then pass back the contents of a buffer& dmabuf?
09:13daniels: efiop: and, again, opengl is going to give you the world's largest headache - there is so so much state it stores in the kernel
09:13daniels: efiop: there is no standard way; it depends on the buffer type
09:13daniels: efiop: this is why i said it was a much more exestential problem
09:13efiop: ok, what about using some kind of screenshot approach?
09:13daniels: efiop: nope
09:13efiop: can we cheat somehow?
09:13daniels: efiop: a screenshot only helps with the contents of what's on the screen at the time, not all the client buffers
09:14ManMower: efiop: even if you solve that problem you're still left with a handful of deal breakers
09:14daniels: efiop: even then - if you scrape all the client buffers and reimport (which isn't 100% possible, but let's pretend it is - you _still_ need a way to tell the compositor that it needs to do that, a place for it to store the data, and a way to get it to restore
09:15daniels: efiop: then you have to bear in mind that it's not just one master session running as a wayland compositor - your web browser will have a wayland compositor internally, maybe your media player, anything for remote display, etc
09:15efiop: but how do vnc-like things deal with that&
09:16efiop: that dont..
09:16efiop: they don't...*
09:18efiop: so, without dumping the buffer contents, we might still be able to dump/restore some apps that do redraw itself regularly?
09:18efiop: like screenserver?
09:18daniels: if the screensaver uses opengl, no, that's not going to work
09:18daniels: at a pinch, your apps might work, as long as you restore their shm segments _exactly_ as they were
09:19daniels: (not posix shm - files created in /dev/shm and then mmaped)
09:20ManMower: apps can interact with other stuff over dbus... how is that state being maintained?
09:20efiop: those segments are shared between client and server?
09:20daniels: efiop: yep
09:20efiop: dbus is not yet supported
09:20efiop: oh, that is bad
09:20daniels: efiop: so you have to preserve the file's storage across reboot, and make sure that client and server's fds and mappings still both point to that same storage
09:20efiop: we would need to dump server too because of that
09:21efiop: and dumping server is very-very-very hard
09:21daniels: from our/protocol point of view, it's the same state as clients handling a crashing compositor, and the answer is the same - for both client and server to each save their state independently at a higher level, and be able to recover that state easily
09:22daniels: i.e. what mobile does and has done for a long time
09:22daniels: any approach which tries to handle it with either side being completely unaware of the details is either going to a) cripple performance, b) not actually really work, c) take basically forever, or more likely d) all of the above
09:23efiop: ok, what about server side. Can we get that info, and pass it to other server(for example when restoring on another machine or after reboot) ?
09:24ManMower: I think the previous conversation already explained why that won't work
09:24ManMower: all the same problems.
09:24efiop: oh... =(
09:25daniels: you can _almost_ do that if you don't have clients using egl/gles, but again that falls into app-specific save/restore, rather than any transparent magic done from within the kernel
09:25daniels: it's a blindingly difficult problem
09:25ManMower: what higher level problem are you trying to solve?
09:25daniels: a look at the line count of drivers/gpu/drm/* might explain why it's so difficult :)
09:27efiop: ManMower: nothing actual... just trying to get at least some support for some apps
09:27efiop: at least as a first iteration
09:28efiop: ok, but there are a lot of apps that are not using gl, right?
09:29efiop: so it is quite possible to support at least some of those apps that are not using gl?
09:29daniels: sure, as long as you can save/restore their mmap'ed storage within the /dev/shm/* files they create
09:29daniels: and keep the link between their mapping and the compositor's
09:29efiop: might using WAYLAND_DEBUG or man-in-the-middle enough to support at least some of apps?
09:29daniels: most of them allocate one or two buffers in /dev/shm up front and cycle between those
09:30daniels: so without saving and restoring that, you're screwed
09:31efiop: thouse buffers are allocated by client?
09:31efiop: and then passed to server?
09:31efiop: if so, it sounds quite possible
09:32efiop: so dumping client calls should be roughly enough?
09:32efiop: how hard does it sound to you?
09:33efiop: daniels: ^
09:34daniels: efiop: i don't think dumping client calls _is_ enough
09:35daniels: efiop: the buffer storage is the files in /dev/shm/*, which are shared between client and server with a fd
09:35daniels: efiop: so you need to make sure the file remains the same, and the mmap() pointers remain the smae
09:35efiop: buffer is created by client and fd is passed by call to server?
09:36efiop: i might be able to fix that mmap pointers when passing to server
09:36daniels: efiop: yep
09:36daniels: efiop: but given most compositors use opengl, really you'd need to start a new compositor, and try to connect various clients by replaying them
09:37efiop: how about just not use compositor?
09:37daniels: err, so you're not using wayland then ...
09:37efiop: oh, damn =)
09:37daniels: (oh also, even if you replay commands, you're not guaranteed that the configuration will be identical, that object ids will be the same, etc)
09:37daniels: this is all part of why i think doing it at such a low level is the wrong approach for something this complex
09:38efiop: what approach would you suggest?
09:38daniels: working at a higher level means that it'll be more useful for moving your state across the network to different machines, or dealing with app crashes, etc etc
09:38daniels: work at the application level
09:38daniels: look at chrome - when it crashes, it knows exactly what state it was in and restores that state by reloading all its tabs
09:39daniels: extend that out to applications in general, which is what mobile's done (android/ios/everything else) for years
09:39efiop: oh, i see
09:40efiop: so app should support something like "close windows" and "open windows"
09:41efiop: so criu would ask it to close windows before dump and ask to open them again after
09:41daniels: ideally each app would be able to dump its entire state at any given point in time (the chrome/sublime text model) and then restore that - restoring a session would then be a matter of requesting some kind of token from the client representing the state (an id, filename, whatever) before you suspend; then you start a new compositor, and start each app with
09:41daniels: the state id you got at suspend, so it can restore to the same place
09:43efiop: yes, that sounds suitable for some kinds of apps that could be just stopped
09:43efiop: and restarted manually
09:43efiop: but criu is more about live-migration
09:43daniels: sure, and i don't see why this wouldn't work for live migration either
09:43daniels: in fact, it's _better_ for live migration
09:43daniels: consider migrating to a machine with slightly different capabilities
09:44efiop: true, but most apps do not support saving state)
09:44daniels: an app is in the middle of 3d rendering, then you switch it to a machine with a slightly less capable gpu that doesn't support all the same extensions - what now?
09:44daniels: whereas with an app-aware state save/restore model, your app would go through its entire startup process, notice that the gpu capabilities were different, and select different rendering paths
09:44efiop: yes, that is a problem...
09:44daniels: (not to mention that migrating opengl state is ~impossible anyway)
09:45efiop: uh... =(... so we probably should stick to using vnc for such things as we do now
09:46efiop: i guess vnc handles all of that for us
09:47daniels: well yeah, but that's not saving and restoring hw state - either vnc is forwarding the gl commands for you, or it's using software rendering for gl
09:47daniels: both of those have a pretty serious performance impact (software rendering more so than forwarding), but forwarding means that criu isn't a kernel thing anymore, it's now a massive userspace abstraction/shim
09:48daniels: and speaking as someone who's written a virtualising opengl shim before, i can really really really really really really really really recommend never doing that
09:48daniels: especially with modern gl which relies much more on auxiliary buffer storage rather than just old-style immediate-mode rendering
09:49daniels: reconstructing the state in such a way that apps don't notice is, basically, a bigger project than just doing suspend/restore within the apps themselves - except it isn't useful for handling apps crashing, will be slower, much harder to maintain for you, etc etc
09:50pippin: ideal apps are stateless
09:51efiop: thanks =)
09:52efiop: i've got a lot of very useful information
09:56efiop: btw, can we patch wayland to give us information about client?
09:57efiop: extend the variety of getters to obtain all needed information including buffers?
09:57efiop: and maybe implement some setters
09:58giucam: you can't fiddle with other clients' state, that is one of wayland goals
09:58giucam: and from inside the client there is no point in having getters
09:58daniels: even given the above, the short answer is no
09:59daniels: well, for software-rendered apps, you could just about manage it
09:59daniels: but as soon as you introduce opengl or media playback, the details of things like buffer allocation are a) driver-specific and b) incredibly complex
09:59daniels: and gl isn't just games - browsers use gl to do composition
09:59efiop: ok, no gl
10:00efiop: and there is a slight chance that those patches might be committed?
10:01daniels: the extension of what giucam's said is that you can't do this from the client - it needs to be done inside the compositor
10:02daniels: and there is no 'the compositor' - some systems will use weston as the display server, gnome uses mutter, there's also qtwayland, etc etc
10:02efiop: but we might patch them in general way too?
10:03daniels: they are completely different codebases, with completely different renderers
10:03daniels: so each project would have to be considered individually
10:04efiop: that is ok=)
10:04efiop: we are very interested in getting criu to support wayland
10:06efiop: ok, so, i guess, we should start and solve the problems as they come into way
10:08daniels: sure, the concern is really just that when you get to gl clients, you'll hit pretty much an intractable problem space - and like i said, that's not just games, it also includes browsers
10:09efiop: daniels: so, approximately, we should patch wayland to support needed getters and setters and then do the same for compositors, and we should be able to dump/restore some nogl apps
10:09efiop: we are okay with not supporting gl apps
10:12daniels: no, not patching wayland - patching compositors to save client state, and somehow restore it when all the clients are moved - which includes preserving all the fds between the client and the compositor, as well as all shm buffer contents
10:28efiop: daniels: but shm buffer is shared with server not compositor?
10:28daniels: efiop: server == compositor
10:28efiop: oh =)
10:29efiop: ok, so patching weston to do that should be a first iteration?
10:30efiop: will weston be an easiest way to start?
10:31daniels: yes, but then again i can't guarantee that those patches would be accepted, since it's quite a large and invasive change
10:31efiop: so you think that the patch size will be quite big?
10:31daniels: the approach we've previously discussed for supporting this is a very small interface to allow apps to support their own save/restore, by providing an app-session token to the compositor that the compositor would then return to the app when it started back up
10:31daniels: yes, i think it would be quite a big undertaking
10:33efiop: ok, cool.
10:34efiop: so the way to go is to go read weston docs? =) maybe there is some article describing data that describes client state?
10:35giucam: yes, but first you need to write them :P
10:35efiop: ok =)
10:36efiop: thank you guys very much! =)
10:36efiop: it was a pleasure talking with you =)
12:22bryce: ManMower, ^^ I went ahead and landed the test fix. I was hoping someone else would RB it overnight, but I do want it included in this week's rc.
12:23bryce: ManMower, so if anyone does have concerns please be attentive to suggestions
12:24ManMower: first person to suggest an xcb rewrite gets to meet me in a dark alley. ;)
12:24JonCruz: anyone else have a patch they want me to review? I attacked the few simple ones that were easy to spot
12:26bryce: JonCruz, there's a handful of patches on the bug tracker: https://bugs.freedesktop.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=wayland&component=weston&component=XWayland&f1=attachments.ispatch&list_id=520118&o1=equals&product=Wayland&query_format=advanced&v1=1
12:26bryce: JonCruz, also many of these need review still: http://patchwork.freedesktop.org/project/wayland/list/
12:27bryce: ManMower, have you heard from any reviewers on your zoom series? If not, I'm going to bump it to 1.8 today.
12:28JonCruz: that 17 patch set might be a bit much. Need a bit more experience with the context
12:28JonCruz: Holy monkey spit!!!!
12:28JonCruz: I think I can attack bug https://bugs.freedesktop.org/show_bug.cgi?id=86815
12:29JonCruz: I'd won an EEE at lug radio live sf. I think it's even here in this room with me
12:31bryce: JonCruz, knock yourself out then
12:31JonCruz: I'll have to assess the effort. If it's reasonable, I can use it in my SCALE talk: "Look! It even runs on this tiny ancient netbook!"
12:34bryce: JonCruz, yeah so maybe leave that for 1.8; that's pretty low in priority
12:34ManMower: bryce: hasn't seen review yet except bill saying it was complicated. I think it should probably be deferred, but http://patchwork.freedesktop.org/patch/39935/ should perhaps land to close the hole
12:34bryce: https://bugs.freedesktop.org/attachment.cgi?id=83633 might be worthwhile, just a configuration check?
12:35bryce: ManMower, ok
14:01bryce: ManMower, could you take a look at https://bugs.freedesktop.org/show_bug.cgi?id=81819 ?
14:02bryce: next week would be fine; I don't think it's urgent for 1.7
14:02ManMower: I thought that was fixed in Xwayland
14:03ManMower: will look into it next week
14:05bryce: ok, so looks like the remaining patches in patchwork and the bugtracker are not urgent. We've made good progress through them this week.
14:06bryce: There's a few more we can look at next week but I think we're closing in on the end of 1.7.
14:06bryce: I'll go ahead and cut the next pre-release now
14:06bryce: if there's any other last minute fixes, or sudden regressions, please let me know asap.
14:06ManMower: http://patchwork.freedesktop.org/patch/41287/ fixes a crash with multi-seat, but I'm not sure how many people really care about multi-seat right now
14:07bryce: yeah I'd rather wait a bit and let it get a proper review. we can always land it next week
14:08bryce: did anyone give a RB on the original version?
14:08ManMower: jpetersen did
14:09bryce: ah ok then
14:09bryce: I remember reading this through myself once or twice
14:10ManMower: the second patch in the series is low pri, nothing but cosmetics.
14:10ManMower: (but also reviewed by jpetersen last round)
14:11ManMower: ooi, is pointer lock likely to land in 1.7?
14:12ManMower: should I flag the bigger zoom series as deferred for now?
14:12ManMower: it changes behaviour enough that I think it's anti-social to rush it in at this point
14:15bryce: what's 'ooi'?
14:16ManMower: out of interest
14:18bryce: pointer lock is on daniels' plate, so I defer to him for the timing of that
14:19bryce: I think we're getting down to the wire though
14:24ManMower: oh, that new rdp fix is probably high priority. I'll see if I can test it myself next week if nobody else does
14:26bryce: ok thanks
14:33bryce: daniels, perhaps by monday you can make a decision on the pointer confinement patchset as to whether that's ready to go in for 1.7 or should be held for 1.8
14:34daniels: bryce: i don't think it's 1.7 material
14:41bryce: daniels, ok thanks
14:56bryce: btw I would love it if someone would give me a Reviewed-By on http://patchwork.freedesktop.org/patch/41150/ ; I'm still having to work around this manually in order to get a clean make check. the release scripts aren't happy about this failure.
14:58bryce: make: *** No rule to make target `en-US/images/x-architecture.map', needed by `en-US/Architecture.xml'. Stop.
15:00JonCruz: bryce: uh oh. Thought I had seen and fixed that in my local merging
15:01bryce: JonCruz, test 'make distcheck' on your end?
15:01bryce:going for coffee, bbiab
15:16JonCruz: bryce: bingo. distcheck fails here but rest works
15:16JonCruz:goes to code up a patch
15:38JonCruz: Hmm... I'd say the reason distcheck is failing is because we have a recursive make instead of a non-recursive one.
16:00bryce: JonCruz, it passed ok last week
16:08bryce: updated the wayland website with latest
16:12bryce: JonCruz, how's the patch coming along?
16:12JonCruz: Yes. I know why it's failing. Got a local build to fail so I can repro
16:13JonCruz: (make distclean;mkdir fooble; cd fooble; ../autogen.sh --prefix=$WLD; make)
16:15JonCruz: Ahh. so it's not that make in publican is being invoked without make in doxygen having been run. That creates nothing.
16:29JonCruz: bryce: rough estimate 1hr +-
16:38bryce: JonCruz, ok
17:09JonCruz: anyone other than bryce care?
17:13bryce: everyone else is probably EOD'd
17:14JonCruz: I thought I found a break I had for out of tree builds, but that didn't fix it completely
17:15JonCruz: turns out Bill's earlier one unifying Client and Server are also bad. No index.html for doxygen gets generated, so my .map files aren't even attempted to be built
17:17JonCruz: oh, wait. not quite. He's getting XML
17:56JonCruz: FAIL: sanity-test
17:57JonCruz: The first one is
17:57JonCruz: test "tc_timeout2_tst": exit status 0, fail.
17:57JonCruz: I shall call that "not my bug"
18:00bryce: JonCruz, are you on ubuntu?
18:00JonCruz: of course
18:00JonCruz: I've been told that's the best
18:00bryce: if so, then yeah known bug. I already posted a fix, it's just waiting someone to give it a RB.
18:10JonCruz: bryce: http://patchwork.freedesktop.org/patch/41485/
18:10JonCruz: bryce: for that test bug, should I review it tonight?
18:10JonCruz: bryce: or are we waiting for outside peeps :-)
18:13bryce: for 41485 I'll just test it and land it; I'm blocked otherwise
18:13bryce: nothing else is going in tonight so may as well wait for reviewers.
18:43bellow: I am trying to reconnect my Magnavox MBP 5120 blu-ray player to my Linksys routers wifi (which I have done before without trouble) and I am getting DHCP cannot be acquired. I have change the IP Address to manual on the blu-ray player without changing the IP address itself and no error. I have checked the routers settings and DHCP is enabled. Is the
18:43bellow: re a way to fix this?
18:49winjo: i want to make a compositor
18:49winjo: well about myself and 4 others
19:09bryce: right-o... wayland 1.6.92 is up.
19:15bellow: I am trying to reconnect my Magnavox MBP 5120 blu-ray player to my Linksys routers wifi (which I have done before without trouble) and I am getting DHCP cannot be acquired. I have change the IP Address to manual on the blu-ray player without changing the IP address itself and no error. I have checked the routers settings and DHCP is enabled. Is the
19:15bellow: re a way to fix this?
19:15mue: how is this related to wayland?
19:23bryce: and there's weston 1.6.92.
19:24bryce: will write up release announcements and post later tonight