| === rsalveti_ is now known as rsalveti | ||
| duflu | RAOF: efifb would be covered by a Mir-side fbdev driver right? | 01:56 |
|---|---|---|
| RAOF | duflu: Yes. | 01:57 |
| duflu | Cool | 01:57 |
| RAOF | duflu: As long as we don't want to handle resolution changes, anything providing /dev/fb0 will do. | 01:57 |
| duflu | Everyone loves to hate fbdev. I'm not familiar with it so don't know why yet. But I'm not impressed at all by DRM either | 01:57 |
| RAOF | Well, fbdev doesn't *do* anything. | 01:58 |
| duflu | Just a header/API right? | 01:58 |
| duflu | Hmm, I didn't realize we'd miss out on mode changing. That's one benefit of SimpleDRM | 01:59 |
| RAOF | Right. | 01:59 |
| RAOF | I mean the API doesn't do anything. | 01:59 |
| RAOF | Other than allow you to mmap /dev/fb?, basically. | 01:59 |
| duflu | Yep, that's the minimum | 02:00 |
| duflu | (with stride and dimension info) | 02:00 |
| duflu | and pixel format | 02:00 |
| RAOF | Yeah, there are ioctls for querying those. | 02:00 |
| RAOF | And for uploading new 256 colour palates! | 02:00 |
| duflu | RAOF: Party like it's 1991 | 02:01 |
| RAOF | Right. | 02:01 |
| duflu | Then again, people still use GIFs with 256-colour palettes | 02:01 |
| duflu | How did GIFs survive? It must have been wide-scale compatibility that made them convenient | 02:02 |
| duflu | That and the patent on LZW expired | 02:02 |
| RAOF | And a pre-calculated, per image 256-colour palate is much less offensive than a system-wide 256 colour limit. | 02:07 |
| duflu | I think even per image it was offensive... but became less so when we stopped measuring pixels in mm :) | 02:08 |
| duflu | and dithering was more effective | 02:09 |
| duflu | RAOF: Only one concern with raw fbdev I think... on some platforms (VMs) the default resolution isn't going to be the desired resolution. Are you saying fix that later? | 02:11 |
| RAOF | Yes, because we can't reasonably fix it with fbdev. | 02:12 |
| RAOF | The user can, however, by setting a video= kernel command line parameter. | 02:12 |
| duflu | Sure. Just means we've all but decided to chase fbdev before chasing SimpleDRM | 02:12 |
| duflu | ... or per-driver mode setting :P | 02:12 |
| RAOF | I don't think that we'll need to do anything to support SimpleDRM other than making mesa handle swrast. | 02:13 |
| RAOF | Well, and for added bonus points do a pixman-based compositor. | 02:13 |
| duflu | RAOF: I'll be more convinced when we have a flag to enable shm on our existing platforms for GL rendering. :) | 02:14 |
| RAOF | Well, that's roughly equivalent to having mesa handle swrast :) | 02:21 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| RAOF | duflu: I'm really conflicted about lp:~duflu/mir/dpi. The more I think about it, the more I think DPI is the wrong thing to be exposing. | 05:47 |
| RAOF | duflu: Because the client wants to render on a 300DPI phone significantly different to on a 300DPI desktop display connected to that phone. | 05:48 |
| RAOF | s/different/differently/ | 05:48 |
| duflu | RAOF: It's a metric both existing toolkits (GDK/GTK) need and also my geometry::Length requires to implement window frames. So we need DPI calculated at some point | 05:48 |
| RAOF | GTK/GDK don't really use DPI though; they use scale-factor. | 05:49 |
| RAOF | Or, at least, GTK apps handle DPIs significantly different to 96 extremely poorly. | 05:49 |
| RAOF | And I think geometry::Length is the wrong measurement. | 05:50 |
| RAOF | Measuring in cm-on-screen is easy, but isn't actually what you want. | 05:50 |
| duflu | RAOF: *Correct* apps will call gdk-screen-get-resolution to size their widgets. That returns DPI | 05:50 |
| duflu | RAOF: Measuring cm on screen is exactly what you want. e.g. the Unity panel is always 0.25" high | 05:51 |
| RAOF | duflu: *GTKs* widgets handle DPI-significantly-different-to-96 really badly. | 05:51 |
| RAOF | duflu: But you *don't* want the Unity panel to be 0.25" high on a phone. | 05:51 |
| duflu | RAOF: More importantly for buttons and text, you're talking a fixed size | 05:52 |
| RAOF | duflu: You want the Unity panel to appear to be the same size as if it were 0.25" on an external display. | 05:52 |
| duflu | RAOF: Ignore phone for the moment (since it's visually different) and consider different monitors. | 05:52 |
| duflu | Yes, if you're displaying a phone status bar, that's always smaller than 0.25" | 05:52 |
| duflu | But ideally always the same physical size | 05:53 |
| RAOF | Right, which is what PPD gets you. | 05:53 |
| RAOF | At least without actual measurements of user-distance. | 05:53 |
| duflu | RAOF: I've hardcoded the viewing distance in the screen perspective transformation. I'm sure with PPD we could still query DPI for easy consumption | 05:53 |
| duflu | RAOF: Regardless, having a DPI value is blocking WM progress | 05:54 |
| duflu | I need to attach a DPI value (or something) to each surface | 05:54 |
| RAOF | Sure! | 05:54 |
| duflu | ... something which is convertible to DPI without additional parameters :S | 05:55 |
| RAOF | I think that is actively harmful. | 05:55 |
| RAOF | Not very harmful, but a bit. | 05:55 |
| duflu | RAOF: I can make perfect DPI-scalable graphics right now, with ease. Just give me a DPI number... from somewhere :) | 05:56 |
| duflu | It's crazy I fought for years to get Unity7 to where it is in 14.04 and still it falls short of the basic requirements I described 2 years ago | 05:57 |
| duflu | RAOF: It's not strictly blocking, however everything that requires a DPI value right now would be hardcoded (e.g. 96) until a real value is available | 05:58 |
| RAOF | duflu: Slurp the DPI from the display, assume 64cm for external monitor and 50cm for laptop, and go :) | 05:59 |
| duflu | RAOF: Or... calculate it precisely using basic math :) | 05:59 |
| duflu | I'm happy to have a configurable scale too | 05:59 |
| duflu | RAOF: But a client can't tell which display it is on, so it requires the server to tell it the physical pixel info | 06:00 |
| RAOF | Sorry, those were viewing distances. | 06:00 |
| RAOF | You can easily get the DPI from the EDID. | 06:00 |
| RAOF | But the client can't render correctly using the DPI. | 06:01 |
| duflu | RAOF: It's trivial. I've been doing it for years. | 06:01 |
| RAOF | (Or, at least, with _just_ the DPI) | 06:01 |
| RAOF | EG: You've got a phone plugged into an external display. Both are 300DPI. You want the output on the external display to be significantly different to the output on the phone. | 06:01 |
| duflu | RAOF: OK I can add viewing distance as a parameter to geometry::Length::as_pixels but I don't think that blocks DPI work | 06:02 |
| RAOF | It's the same API. | 06:02 |
| RAOF | Or, rather, it's an API for the same purpose. | 06:02 |
| RAOF | Unless we add in the DPI API now, then deprecate it when we put in the proper solution. | 06:03 |
| RAOF | Which is viable, I guess. We're planning on breaking API, why not one more thing? :) | 06:04 |
| racarr__ | how about everytime you break API you also have to opaquify an existing client struct | 06:04 |
| RAOF | :) | 06:04 |
| duflu | Or fix 10 bugs :) | 06:05 |
| duflu | RAOF: If you can propose the more generic solution that would be great. In the mean time I'm not blocked and will just assume 96ish DPI where the value is required | 06:07 |
| duflu | Hmm, or is it just a second attribute? | 06:07 |
| duflu | mir_surface_attrib_viewing_distance | 06:07 |
| RAOF | It's modelable as a second attribute. | 06:08 |
| RAOF | As I wrote on the MP, I think the tuple {DPI, form_factor, PPD} expresses everything that a client might possibly want to know (but would prefer to not expose DPI, on the basis that clients are unlikely to use it well) | 06:09 |
| duflu | Which can also be assumed as a hardcoded value for now. Its later introduction doesn't change the physical size of an inch | 06:09 |
| duflu | RAOF: I'm also conflicted with dreams of eventually doing head tracking to update the real eye vector :) | 06:11 |
| RAOF | duflu: Totally possible! Laptops will ship with kinect in the not-too-distant future! | 06:11 |
| duflu | But that too does not change the definition of an inch | 06:11 |
| RAOF | duflu: But *does* change what should be rendered. | 06:11 |
| RAOF | It certainly doesn't change the physical DPI of the display, but the physical DPI of the display was never what you wanted in the first place; you always wanted apparent-size. | 06:12 |
| RAOF | Or, rather, you want the DPI in order to determine how big to draw things. You want to determine how big to draw things so that they appear to be an appropriate size to the user. | 06:13 |
| duflu | RAOF: Physical size is important. That dictates the reasonable minimum size of any touch-button on a phone or a big screen. In cases like that, viewing distance must be approximately equal to reach out to | 06:13 |
| RAOF | We could just tell you how big to draw things so that they appear to be an appropriate size. | 06:13 |
| RAOF | To reach out to...? | 06:14 |
| duflu | To physically touch. That said, design requirements change too. Like how an ipad has bigger icons to an iphone | 06:15 |
| duflu | You're still holding them at the same distance | 06:15 |
| RAOF | I don't think that's the case, actually. | 06:16 |
| RAOF | I think people tend to hold phones closer than tablets. | 06:16 |
| * duflu refuses to continue that far down the hypothetical path | 06:17 | |
| duflu | Time to do other work | 06:17 |
| RAOF | (Apple at least think people hold iPhones ~25cm from their eyes, and iPads ~38cm ☺{) | 06:17 |
| RAOF | Yeah, certainly. | 06:17 |
| duflu | Well, if anyone's done the physical research then it would have been Apple | 06:18 |
| duflu | I find that odd | 06:18 |
| RAOF | Tablets are bigger :) | 06:18 |
| duflu | 25cm is very close. Are people blind? | 06:19 |
| * RAOF has just determined that he holds his phone between 28cm and 24cm away from his nose. | 06:20 | |
| duflu | Hah, I just measured 39cm for iPhone :) | 06:24 |
| RAOF | Wow. That's getting pretty close to arms-length. | 06:26 |
| duflu | No, still pretty bent in the elbow | 06:27 |
| duflu | Arms length is about 60cm | 06:27 |
| RAOF | Dear “bzr heads”: please find that branch head you seem to have deleted somehow. | 06:32 |
| RAOF | Woo! | 06:40 |
| === mpt_ is now known as mpt | ||
| greyback | hey folks, quick question: for screencasting, is the intention for the screencast app to connect to the system compositor (as that is what pushes the final pixels to the screen) or to the session compositor? | 11:17 |
| alan_g | greyback: is that for Mir to decide? Doesn't that question come down to the needs of the screencast app? (E.g. does it screencast the user session or does it want to "cast" lock screens and switching users? | 11:21 |
| alan_g | ) | 11:21 |
| alan_g | My guess would be it should be to the session server. But I'm not designing screencast. ;) | 11:22 |
| greyback | alan_g: fair point, I can't say what the intention was, but I can ask what he requirements for the feature were :) | 11:22 |
| alan_g | alf_: Mir's "screencast" should support both scenarios ^^ right? (But connecting to the system compositor ought to be privileged.) | 11:24 |
| alf_ | alan_g: greyback: Right, you can connect to any mir server (nested or host) and get that server's output | 11:26 |
| alf_ | alan_g: greyback: (if you have the needed priveleges of course) | 11:27 |
| alf_ | s/priveleges/privileges/g | 11:27 |
| greyback | alf_: yep, that's clear. I'm trying to see how QtCompositor will work with the screencasting stuff | 11:27 |
| greyback | so was curious if I had to care at all (only system compositor would be used for screencasting) or if I did have to care | 11:28 |
| * greyback thinks he has to care :) | 11:29 | |
| alf_ | greyback: hmm, yeah, screencasting uses the DisplayBufferCompositor(Factory) interfaces currently | 11:29 |
| greyback | alf_: to just check I understand it, for screencasting you create a new GL context, a new renderer for that context and have it render to an FBO, which then you glReadPixels back? | 11:31 |
| alf_ | greyback: right, except we don't glReadPixels in the server. We create a new hardware buffer to back the FBO, render into it, and send that back to the client. Then the client can do what it wants with it (our official screencasting client glReadPixels). | 11:35 |
| greyback | alf_: gotcha | 11:35 |
| greyback | alan_g: can I confirm your intention to eventually remove mir::scene::SurfaceConfigurator? | 11:36 |
| greyback | alan_g: and is everything wired up so I could replace my use of it with mir::scene::SurfaceObserver? | 11:39 |
| alan_g | greyback: Sorry that works's several levels down my stack - I need to review to give a good answer. | 11:40 |
| greyback | alan_g: that's ok. I'm in absolutely no rush for an answer | 11:41 |
| * alan_g promptly forgets about the question | 11:42 | |
| === alan_g is now known as alan_g|lunch | ||
| greyback | another quick question | 12:30 |
| greyback | geometry::Size size() const override; | 12:30 |
| greyback | geometry::Size client_size() const override; | 12:30 |
| greyback | in BasicSurface | 12:30 |
| greyback | what is the difference exactly? One the actual geometry of the surface in pixels, the other the size it should actually be rendered at (i.e. scaled) | 12:31 |
| greyback | ah, never mind | 12:32 |
| greyback | basic_surface.cpp: // TODO: In future when decorated, client_size() would be smaller than size | 12:32 |
| greyback | which troubles me, what has decoration got to do with a client's surface? | 12:34 |
| === alan_g|lunch is now known as alan_g | ||
| alan_g | greyback: You're best talking to duflu - he's got plans in this area that mean the area of a surface Mir renders can be larger than the area the client is made aware of. | 13:00 |
| greyback | alan_g: indeed. Will have a chat with him | 13:00 |
| kgunn | 709cardinal | 13:10 |
| kgunn | oops wrong window | 13:11 |
| === tedg is now known as ted | ||
| * greyback theorizes what kgunn was writing about in that other channel | 13:15 | |
| kgunn | my address | 13:15 |
| === chihchun is now known as chihchun_afk | ||
| alan_g | alf_: do you have an opinion on https://code.launchpad.net/~alan-griffiths/mir/introduce-yet-another-interface-into-frontend/+merge/218667? | 13:45 |
| alf_ | alan_g: haven't looked yet, will do so shortly | 13:46 |
| === chihchun_afk is now known as chihchun | ||
| === alan_g is now known as alan_g|tea | ||
| === dandrader is now known as dandrader|afk | ||
| === alan_g|tea is now known as alan_g | ||
| === chihchun is now known as chihchun_afk | ||
| === pete-woods is now known as pete-woods-lunch | ||
| === dandrader|afk is now known as dandrader | ||
| josharenson | kgunn, how would you like me to proceed re: glmark2 android off-screen (or the lack thereof) | 15:27 |
| kgunn | josharenson: do you have an inkling of how to enable it ? | 15:28 |
| kgunn | josharenson: second question, does everything hit 60 fps ? | 15:28 |
| kgunn | on android | 15:28 |
| kgunn | on nexus4? | 15:29 |
| kgunn | (running on n10 & n7 pure droid might be interesting also) | 15:29 |
| josharenson | kgunn, I'll run it an see... as for enabling it, I looked for a few ways, and there wasn't anyhting easy... | 15:29 |
| josharenson | kgunn, you can disable vsync, but it seems to only be app side... | 15:30 |
| josharenson | kgunn, I'll look at the code too | 15:30 |
| kgunn | josharenson: thank...yeah, i don't want you to go down a rathole...but worth a look | 15:36 |
| josharenson | kgunn, would the on screen numbers be of value, across devices? | 15:36 |
| kgunn | josharenson: i think so, it will show some relativism and effect of gpu | 15:37 |
| kgunn | sensitivity | 15:37 |
| josharenson | ok | 15:38 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === fginther is now known as fginther|lunch | ||
| === fginther|lunch is now known as fginther | ||
| josharenson | alf_ are you aware of any way to run glmark2 off screen on android? looks like its not implemented... | 16:45 |
| kgunn | kdub_: you back ? | 16:47 |
| kdub_ | kgunn, yep! | 16:47 |
| kgunn | welcome back! hope it was a good time of | 16:47 |
| kgunn | off | 16:47 |
| kdub_ | thanks! | 16:50 |
| === pete-woods-lunch is now known as pete-woods | ||
| === alan_g is now known as alan_g|EOD | ||
| kdub_ | looks like time to upgrade to utopic | 17:09 |
| racarr__ | http://richg42.blogspot.co.uk/2014/05/things-that-drive-me-nuts-about-opengl.html | 17:30 |
| racarr__ | from a dude at valve, its interesting | 17:30 |
| racarr__ | he has lots of bullet points ;) | 17:30 |
| racarr__ | alf_: I sa you filed a bug about the custom input dispatcher fixture failure are you orking on it? | 17:33 |
| racarr__ | I ran in to it too | 17:33 |
| slvn_ | hello, a little question : | 17:40 |
| slvn_ | I have ubuntu 14.04, I give a try and setup unity8 + mir | 17:40 |
| slvn_ | My touchscreen is not used ! only my mouse is detected | 17:41 |
| slvn_ | but I have the /dev/input/mice with receive both mouse and touchscreen information | 17:41 |
| slvn_ | do I need to configure something special? | 17:42 |
| racarr__ | slvn_: :) Thanks for testing...you are the second person to bring this up so I guess I should take some time to look at it. | 17:42 |
| racarr__ | slvn_: I think its basically just a bug on our end... | 17:44 |
| racarr__ | for the touch devices e look for these device configuration files | 17:44 |
| racarr__ | that arent present ont he desktop | 17:44 |
| slvn_ | racarr__, yes, my touchscreen is still under warranty :) | 17:44 |
| racarr__ | I may be able to suggest a workaround | 17:45 |
| racarr__ | if you are interested in testing | 17:45 |
| slvn_ | racarr__, is there some configuration file that patch | 17:45 |
| racarr__ | need just a minute or to to figure out | 17:45 |
| racarr__ | maybe! | 17:45 |
| slvn_ | racarr__, yes | 17:45 |
| racarr__ | this is some code we inherited from android open source project | 17:45 |
| racarr__ | so I have to remind myself...hat it does | 17:45 |
| slvn_ | racarr__, I am fine to test a workaround, because my goal is to test something more complicated afterwared | 17:45 |
| racarr__ | oh boy fun :D | 17:46 |
| racarr__ | slvn_: Ok can you run unity8 or mir_demo_server_basic for me (make sure to run demo_server as root so it can open input, otherwise you cant quit ith ctrl+Alt+backspace) | 17:51 |
| racarr__ | with MIR_SERVER_LEGACY_INPUT_REPORT=log | 17:51 |
| racarr__ | slvn_: and I guess riter stdout/stderr to a file we are looking | 17:51 |
| racarr__ | for some messages about opening input configuration files | 17:52 |
| racarr__ | to find what it is calling your touch screen | 17:52 |
| racarr__ | then we will make a conf file | 17:52 |
| racarr__ | slvn_: IF you run unity8 yourself you will also need to run it as root...from a VT like sudo QT_QPA_PLATFORM=ubuntumirserver MIR_SERVER_LEGACY_INPUT_REPORT=log unity8 > input-log.txt 2>&1 | 17:56 |
| slvn_ | racarr__ of course, I need to close my X session right? | 17:58 |
| racarr__ | slvn_: No you should be able to just run it from a VT | 18:00 |
| racarr__ | and even switch back and forth | 18:00 |
| racarr__ | beteen your X VT and Mir :) | 18:00 |
| === dandrader is now known as dandrader|lunch | ||
| racarr__ | slvn__: Uhoh...did we kill your machine ? | 18:05 |
| slvn__ | racarr__, yes some trouble :) | 18:05 |
| racarr__ | hmm what happened? | 18:06 |
| slvn__ | I probably didnt do the command correctly ... | 18:06 |
| racarr__ | I mean ho did it break though? | 18:07 |
| slvn__ | can you copy paste the command again (my textfile hasn't been save) | 18:07 |
| slvn__ | mir is displayed | 18:07 |
| slvn__ | but could get out of it | 18:07 |
| racarr__ | oh did you forget to run as root? | 18:07 |
| slvn__ | so I rebooted .. | 18:07 |
| racarr__ | maybe missed the sudo | 18:07 |
| racarr__ | sudo QT_QPA_PLATFORM=ubuntumirserver MIR_SERVER_LEGACY_INPUT_REPORT=log unity8 > log.txt 2>&1 | 18:08 |
| racarr__ | should be the stuff | 18:08 |
| slvn__ | terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >' what(): Error opening DRM device | 18:08 |
| racarr__ | but it worked ithout root? Hmmm | 18:09 |
| racarr__ | very strange... | 18:09 |
| racarr__ | *thinks* | 18:10 |
| slvn__ | in a terminal, doing Alt+F1 | 18:10 |
| slvn__ | in root | 18:10 |
| racarr__ | slvn__: You mean a virtual terminal yes | 18:10 |
| racarr__ | not a terminal in X11 | 18:10 |
| slvn__ | yes, a VT | 18:10 |
| slvn__ | I need to reboot that in a VT | 18:11 |
| slvn__ | hold on... | 18:11 |
| slvn__ | I need to redoo that in a VT | 18:11 |
| racarr__ | :) | 18:12 |
| slvn__ | ok got it | 18:13 |
| racarr__ | slvn__: Yay, can you put the log on a pastebin? | 18:14 |
| slvn__ | http://pastebin.com/nBkF7dz9 | 18:15 |
| racarr__ | slvn__: Ah...hmm its actually failing earlier than I guessed | 18:18 |
| slvn__ | I have a laptop with a trackpad + a mouse (evoluent) + a usb keyboard + an external monitor with touchscreen | 18:18 |
| racarr__ | so I dont really have a workaround...sorry lol | 18:18 |
| racarr__ | this is helpful though...I can see where it fails so ill look in to it and try and get something fixed | 18:18 |
| slvn__ | racarr__, where does it fail exactly ? | 18:20 |
| slvn__ | in /dev/input/mice ? | 18:20 |
| racarr__ | slvn__: Yeah around line 20 | 18:21 |
| racarr__ | its trying to get...some sort of driver info ith some sort of IOCTL Thats not supported on the desktop | 18:21 |
| racarr__ | and apparently there is a fallback for the builtin mouse but | 18:21 |
| racarr__ | the touchscreen just fails | 18:21 |
| slvn__ | ok :( | 18:21 |
| slvn__ | it is working on ubuntu 14.04, but not with unity8. though | 18:22 |
| racarr__ | slvn__: Mm. makes sense. | 18:22 |
| racarr__ | slvn__: I think it wont be hard to fix...if you want I can try and prepare a branch for you to test later today | 18:23 |
| racarr__ | (I dont have a desktop touchscreen) | 18:23 |
| slvn__ | Yes, that would be nice :) | 18:26 |
| slvn__ | I dont know how hard this is to compile unity8 | 18:26 |
| slvn__ | +mir | 18:26 |
| racarr__ | slvn__: Ok great. Will you idle around in the IRC channel so I can catch you sometime later today or tomorrow (I am us pacific time) | 18:26 |
| racarr__ | or should I send you an email? | 18:26 |
| racarr__ | or I guess we could use a launchpad bug haha | 18:27 |
| slvn__ | I am in europe | 18:27 |
| slvn__ | by email | 18:27 |
| racarr__ | slvn__: Ok. Wanna pm me your email and I ill try and work on something with instructions to test this afternoon | 18:28 |
| slvn__ | maybe we could first try the piece of could that should do the ioctl on /dev/input/* | 18:28 |
| racarr__ | and you should get them tomorro :) | 18:29 |
| racarr__ | yes I think hat is going on is the ioctl is to read | 18:29 |
| racarr__ | some like, identifier tag for the device that seems to only work on android | 18:29 |
| racarr__ | to try and load a device configuration | 18:30 |
| racarr__ | so I think we can just build in a default touchscreen configuration | 18:30 |
| racarr__ | which will work on the desktop | 18:30 |
| anpok | ha someone looked into the clang ci failures.. | 18:50 |
| anpok | there was one error that happened on my and on alfs mp | 18:51 |
| anpok | could reproduce locally | 18:51 |
| anpok | *could not :) | 18:51 |
| racarr__ | I havent looke dyet happened to my MP too though | 18:57 |
| racarr__ | anpok: Hmm wait | 18:58 |
| racarr__ | looking at the tests... | 18:58 |
| racarr__ | can you run a server process without ac lient with our test fixture | 18:58 |
| racarr__ | when the last client exits | 18:58 |
| racarr__ | the server process is stopped by the fixture | 18:58 |
| racarr__ | which is why all these input tests only set client_may_exit fence after | 18:58 |
| racarr__ | all the expectations are validated | 18:59 |
| racarr__ | just a guess :) | 18:59 |
| anpok | a failure only with clang in the bespokedisplayserver fixture based tests | 18:59 |
| === dandrader|lunch is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| === jono is now known as Guest3239 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!