Re: Wayland design principles (Re: wayland and gambas)
On Monday 29 April 2024 22:23:44 GMT-7 Carsten Haitzler wrote: > > There is worry in our community that Wayland is going to take over and x11 > > will become obsolete. > > It's inevitable. We're just arguing on timescales (I think Wayland will need > more time to mature but it'll get there). I used to too, but I think we'll see X.org removed from non-LTS distros by the end of the decade. At a minimum, I don't see it being offered as a default for desktop distros; you'll need to install with Wayland and then later switch to X11. > You might not be, but you may run some app you download from some random > place on the internet you THINK is nice (some sodoku game trinket thing) > but it's actually trying to steal your banking details... This is only > getting worse in a world of snaps/flatpaks ... And even if most people on this list don't do that, there are people who do. I refuse to run proprietary code as much as I can, and when I can't I want it to run as a separate user (thus non-graphical) with very strong system protections in the systemd .service file. But I have several colleagues who download flatpaks and similars. Wayland has to be designed with that in mind. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Cloud Engineering
Re: Wayland design principles (Re: wayland and gambas)
forgot the screen grabs not being available is a downgrade for us. > For example simple colour picker routines many of us have don't work now. > Eg. > PickedColour = Desktop.Screenshot(Mouse.x, Mouse.y).Image[0, 0] You *can* still get a screenshot from which to pick a pixel's colour. It just involves asking the compositor for it, because we don't want random applications doing that without notice. > It was that simple. It can still be. Nothing in the protocol or extensions mandates that the above change. > I hope you understand our dilemma here. I do not. I repeat that most of your concerns can be addressed, if you explain the use- case and the need, not the means by which you've solved that need in the past. Not all of them (maybe not even most of them) will be addressed, but you won't know until you try. The Wayland community has been around for over 15 years. I think you should have started participating earlier, but better late than never (or when X.org stops working and is removed from Linux distributions). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Cloud Engineering
Re: Wayland design principles (Re: wayland and gambas)
On Monday 29 April 2024 10:05:32 GMT-7 Bruce Steers wrote: > I guess/hope a similar thing will happen to x11 or Wayland will accept this > particular issue needs addressing and provide a workaround. > > As fundamentally Wayland principles are to us, restrictive in a way that I > think many will simply not tolerate. Please describe the need you have, not the means by which you think you can solve the need. For example, why do you think you need to specify absolute positioning for certain windows? The Wayland philosophy on this has been that the compositor knows best where to place the windows for regular applications. That does not include fixed desktop components, such as the task bar or desktop wallpapers, but those need to communicate directly with the compositor they are a desktop for. Someone may have said they had a need to grab the keyboard and obtain key events even when the window wasn't focused. But why is that? X11 uses keyboard-grabbing to implement dismissal of popup menus, something that Wayland solved properly instead. Another use-case was to ensure that focus couldn't be stolen while typing a password... again, Wayland can solve that by the window describing itself as "I'm recording a password" so the compositor can implement a higher focus-stealing threshold or other attention-grabbing techniques (how many of us have typed passwords in the wrong window?). Other things are done for security: you can't inject events into other windows, so we lose the auto-type feature in KeyPassXC. You can't perform arbitrary screengrabs any more, but instead screensharing applications must ask the compositor to let the user choose which window(s) to share. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Cloud Engineering
Re: Wayland design principles (Re: wayland and gambas)
On Monday 29 April 2024 10:17:53 GMT-7 Bruce Steers wrote: > I thought to redesign my software using a system tray as there was no way > to position a window but without system tray working I'm stuck for ideas. The system tray is not conveyed through Wayland in the first place (it goes through D-Bus), so any issues you may be facing aren't Wayland. It's possible the SNI implementation you've got access to is broken and system trays work on X11 because it falls back to the old XEmbed. It might also be an issue with your specific desktop of choice. Either way, the system tray is not a Wayland issue. I recommend treating it as a regular bug and working with the implementation's and desktop's developers to fix it. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Cloud Engineering
Re: Wayland design principles (Re: wayland and gambas)
On Monday 29 April 2024 05:43:30 GMT-7 Pekka Paalanen wrote: > The system tray case I am not familiar > with, so I cannot say anything about that. That sounds like the issue is not using the StatusNotifierItem[1] specification. The old XEmbed system tray protocol is not expected to work on Wayland. I don't know if xembedsniproxy works on Wayland, actually. It's running on my machine but I don't know if anything is using it. So turning the question back to Bruce: have your applications been updated to use the SNI protocol? It's over 10 years old now. [1] https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/ -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Cloud Engineering
Re: [PATCH] scanner.c: prefer strchr() over for loop and toupper() in place
On Wednesday, 3 January 2024 02:48:26 -03 James Tirta Halim wrote: > - u = xstrdup(src); > - for (i = 0; u[i]; i++) > - u[i] = toupper(u[i]); > - u[i] = '\0'; > + dst = u = fail_on_null(malloc(strlen(src) + 1)); This does have the advantage of not writing to every byte twice, just once. However, the big elephant in the room is that: > + while ((*dst++ = toupper(*src++))); You're violating the rule of use of toupper/tolower: NEVER. Those functions have a design flaw that they operate on bytes, not on full strings. Uppercasing and lowercasing need to see more than one byte to be accomplished correctly. Moreover, those two functions are locale-dependent, so the output of this function is also locale-dependent, something that the scanner probably shouldn't be. Try testing the tool with an 8-bit Turkish locale to see what happens. I suggest you ditch toupper() in the first place and just do the ASCII uppercasing manually. PS: I suggest either moving the ; to the next line or using brackets to make it evidently clear that you intended an empty while loop. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Re: Weston 12 compatibility with Yocto Kirkstone
On Thursday, 15 June 2023 04:30:52 PDT Namit Solanki (QUIC) wrote: > Hi Wayland / Weston developers, > > As we all know Weston 10 has bitbakes files available for Yocto kirkstone > version. Can Weston 12 work with Kirkstone as well? > > Is Weston 12 compatible with Kirkstone? > > Do we need to write our own bitbake files for Weston 12 to compile with > Kirkstone? I should point out that you're supposed to simply update your Yocto Project releases. That's one of the two major objectives of YP, alongside having BSPs in the first place: keep your device's configuration, just update the layers to the latest, and you've got an updated image for your device's new release. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Re: How to set a recursevly PATH under wayland
On Saturday, 13 May 2023 05:51:28 PDT Zener wrote: > Can I use something similar for the wayland enviroment? That question should be asked of your compositor, not of Wayland. Most compositors have the ability to source some shell script before or after they're started. For a Plasma Wayland desktop, it's ~/.config/plasma-workspace/env/. You can also add it to your shell login scripts, those are usually sourced too, but check with your compositor. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Re: Window positions under wayland
On Thursday, 4 August 2022 18:01:34 PDT Igor Korot wrote: > The very first time the application starts - it will be at position > (100,100) Then user drags the window to a position (50, 50) and closes the > application. When he tries to open it next time - (s)he expects the window > to be placed at position (50, 50). Rephrasing in Wayland's world: the first time the window opens, it opens at a position determined by the compositor. The user drags the window, then closes. The next time the window opens, if the compositor was configured to do so, it will open where it was last seen. I don't see anything wrong with this. > Resolution changes should affect the sizing - not position. No, they are about position too. 100,100 on a 1920x1080 resolution is about 5% to the right of the left edge and 10% from the top. 100,100 on 3840x2160 is 2.5% from the left and 5% from the top, on the same monitor. The user has a right to expect the same finger-width position on the screen, relative to where their eyes are looking at. > Again when you say "clients" - are you talking about software or developers. He's talking about applications. Terminology from X11 and Wayland: the X11 server and the Wayland compositor are servers, the applications connect to them and are thus clients. > However, please remember that HiDPI monitors for laptop is relatively > new things They've existed for at least 10 years and have become ubiquitous in the last 5 or 6. Regardless of whether you've got one or most people have one, we have to design the future for them. > We are now talking about the OS and physically plug or unplug the monitor. > Plugging in the new monitor shouldn't affect anything on the way the > application starts. Yes, it should, if the primary monitor changes. Right now, I am writing to you on a 4K monitor @ 3840x2160 resolution, located to the right of the laptop screen (also 4K @ 3840x2400). My primary monitor is the one big one, on the right, not the one that contains (0,0). That's the one I am looking at, and I have positioned it so it's in front of me and my eyes are level with about 1/3 from the top of the monitor. I expect application windows to show up in front of me, not 30° to my left and 15° downward angle, which is where the laptop is. Any application that remembers its absolute position has, by simple construction, *buggy* UX. And on X11, this happens a lot. The email compositor window *always* shows on the left monitor, regardless of where the mouse pointer is or I last closed it. One of my browsers shows up on the last monitor which I used it, which means about 50% of the time it's wrong too because I disconnect the big monitor and take the laptop with me. As Carsten said, it's far easier to fix the half a dozen compositors that exist to understand how the user wants the set up configured than the hundreds of applications that each would otherwise control their positions. At best, we could fix this in the toolkits (there are basically three of them of relevance at this point), but we might still have incompatible behaviour depending on which application we the user is using. > I don't set the explicit parent to the dialog which means it will have a > Desktop window as a parent. > And when I call Center(), I do expect the dialog to be centered. If you did pass a parent, then sure, centering on the parent makes sense and the compositor may obey you. It might also think that new windows should appear horizontally centre, but vertically at the top (macOS does this). If you did not pass a parent, then you have no right to expect any position relative to the desktop. The Compositor shall choose the best position for the new window. It might be centred, or it might be such a way that it won't obscure other windows that are already open. Often, it's the screen where the pointer mouse is, but there are systems without mice. The important thing is that the compositor does this for all windows, based on the hints supplied by the application. A modal dialog is different from a modeless dialog, which is different from a TLW, which is different from a floating tool window. This means it *does* have a standard for all windows and the behaviour is predictable. Allowing each window to position itself means that it is not standard and is not predictable, depending on whether the developer of the application in question thought it was a good idea and coded it that way -- per window of each application. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Re: Window positions under wayland
On Thursday, 4 August 2022 16:01:23 PDT Carsten Haitzler wrote: > there might be bigger picture ideas BEHIND that like "i have a password > dialog for my db app" - then great. make that dialog as such and make sure > the compositor knows what window it is a dialog for and a good > wm/compositor will just magically open it centered over the parent window > (or over the top center or bottom-right corner or whatever the policy that > wm has for dialogs is - but at least it's now consistent for all apps with > dialogs - if that is what the wm does - enforce consistency). if the > wm/compositor does stupid things with dialogs and places them at $RANDOM > positions then feel free to yell at the compositor for being stupid. there > are very many fewer wm and compositors out there to yell at than there are > applications to yell at, so it's more scalable to have the fixes put in > compositors not apps. if you absolutely MUST have fine control over this .. > as i said - you can render in-line in your window, use subsurfaces etc. but > then you are limited as i described. Indeed, this is mostly an X/Y problem. You have an X problem (unrelated to X11, just using the letter of the alphabet) and you think you need Y to achieve it, as in the example above: in order to properly place some dialog, the application needed to get the absolute position of the window it's going to be relative to and then position the new window at a specific absolute position. So we get people coming and asking about how to do Y (this implementation). Instead, we need to know what the X problem was: properly positioning the sub- window or sibling window, or application window reappearing close to where you've last seen it. There are probably better ways of solving that problem than the reintroducing all the legacy that Carsten is talking about. This is why Wayland developers keep saying that absolute positions being unavailable is a feature, not a bug. There may come a time when the number of protocol extensions to support all the little things that one could do with absolute positioning becomes a burden, but we're not there and have yet to see a problem that can't be solved differently. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Re: Dynamically loading libwayland complications
On Tuesday, 28 June 2022 19:00:26 PDT Campbell Barton wrote: > Hi, recently I was looking into dynamically loading libwayland to be > able to support both X11 and Wayland, without requiring libwayland. > For our project is currently a requirement for adopting Wayland. Simplify your problem by dynamically loading a plugin that links to libwayland, instead of dynamically loading libwayland. > From what I can tell there is no portable way to wrap > `wl_proxy_marshal_flags` see [0], > Using GCC's `__builtin_apply` does work but this isn't available in > CLANG so I'd prefer to avoid it. > The only portable way I found to handle this was to create a header > that needs to be included before any of the headers generated by > wayland-scanner (which make calls to `wl_proxy_marshal_flags`), which > can be replaced by a reference to a function pointer instead of > requiring the function to exist and link at build time. How is this different from any other function from libwayland, variadic or not? If your code isn't linking to libwayland, then it can't call any of those functions. Therefore, you must be using a code generator that is calling something other than those functions. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering
Re: kwin_wayland: ../libepoxy/src/dispatch_common.c:872: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed.
On Wednesday, 25 May 2022 13:18:11 PDT Carlos wrote: >Model name: Cortex-A72 This is a 64-bit capable CPU, according to Wikipedia: https://en.wikipedia.org/wiki/ARM_Cortex-A72 Why are you running 32-bit? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering
Re: kwin_wayland: ../libepoxy/src/dispatch_common.c:872: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed.
On Monday, 23 May 2022 13:42:45 PDT Carlos wrote: > :) I know. 32-bit. But I have no option > > processor : 3 > model name : ARMv7 Processor rev 3 (v7l) > BogoMIPS: 144.00 > Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 > idiva idivt vfpd32 lpae evtstrm crc32 > CPU implementer : 0x41 > CPU architecture: 7 > CPU variant : 0x0 > CPU part: 0xd08 > CPU revision: 3 Are you sure you have enough RAM for the purpose you're trying to use this device for? You should consider either upgrading to something more modern or limiting your use of this old, embedded device. I'd never even heard of armv7l until your email (I only knew of -A, -M and - R). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering
Re: kwin_wayland: ../libepoxy/src/dispatch_common.c:872: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed.
On Monday, 23 May 2022 11:07:35 PDT Carlos wrote:
> QImage::scaled: Image is a null image
This first line probably indicates an out-of-memory condition: some operation
prior to this failed to allocate memory for its image, so scaled() simply
complained that there was no image to scale. All the other errors after this
could be related, like:
> plasma_workspace_pipewire_logging: Failed to query DMA-BUF format count.
This could be that it can't get the some information because the image was
null. But, looking at the code, it looks more like more memory allocation
failure:
EGLint count = 0;
EGLBoolean success = eglQueryDmaBufFormatsEXT(display, 0, nullptr,
);
if (!success || count == 0) {
qCWarning(PIPEWIRE_LOGGING) << "Failed to query DMA-BUF format
count.";
return {};
}
> kf.plasma.quick: Couldn't create KWindowShadow for ToolTipDialog(0x2905a50)
Ditto.
So my conclusion is that you're out of memory, most likely due to a memory
leak somewhere. All the error messages except for the kwin_wayland one from
plasma, so it could be a memory leak in plasma.
> kf.baloo.engine: Running on 32 bit arch, limiting DB mmap to 1 GByte
Why are you running on 32-bit?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel DPG Cloud Engineering
Re: Basic API usage
On Wednesday, 9 September 2020 02:50:21 PDT Pekka Paalanen wrote: > > Well, the last time I've read some C-language specification many years > > ago, the one thing that it really made clear was you can count on > > everything is completely undefined. > > Ha, yeah. C'mon, you know it isn't true. There's also plenty of unspecified behaviours, implementation-specific behaviour, and quite a few "ill-formed, no diagnostic required". -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Direct Framebuffer (FreeBSD)
On Tuesday, 21 July 2020 12:15:03 PDT Lonnie Cumberland wrote: > On the other hand, they do have builds for the latest RDP client > applications for Wayland and I was even able to compile it myself, but just > do not have a Wayland server set up and am trying to find the simplest > solution to use Wayland without Xorg so that I can use the RDP client as > well as to keep the total footprint as small as possible. So all you want is Weston plus your application. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland Direct Framebuffer (FreeBSD)
On Sunday, 19 July 2020 16:55:01 PDT Lonnie Cumberland wrote: > I am working on a speciality project for a super ultra-thin distro that > will basically run just a single graphical application in a type of Kiosk > (fullscreen) mode and Xorg is just WAY too large for what I want to do. If you're running a single application, can you make that application use DirectFB or DRM directly? You don't need Wayland for a single, full-screen application using the display. Wayland is more useful when you need to share between two or more applications. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland 4/6] tests: Use volatile pointer for NULL dereference
On Tuesday, 28 August 2018 23:17:13 PDT Daniel Stone wrote: > Clang warns that it can silently discard a non-volatile write to a NULL > pointer (perhaps it constitutes undefined behaviour?), and recommends It is. > changing it to volatile. That doesn't help. It's still UB and can be discarded because you're not allowed to provoke UB. If you need to write to a whose value is identical to NULL, write assembly. How about a raise(SIGSEGV) instead? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Window positioning
On Tuesday, 2 January 2018 23:37:08 -02 Han, Guowei wrote: > Thanks Jasper. Do u know if there's a demo i can learn from? Currently i am > creating a bigger surface bigger than screen size. and make subsurface so i > can posion them as i want. Really don't think its a good way to do it. It isn't. Can you share why you want to position a window at a specific point in the screen? What's your use-case? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] cursor: Use shm_open() instead of XDG_RUNTIME_DIR files
On Wednesday, 18 October 2017 07:05:46 PDT Matt Hoosier wrote:
> On Wed, Oct 18, 2017 at 4:23 AM, Quentin Glidic
>
> <sardemff7+wayl...@sardemff7.net> wrote:
> > + fd = shm_open("/wayland-cursor-shared", O_CREAT | O_RDWR, 0);
> > + shm_unlink("/wayland-cursor-shared");
>
> This seems to be a departure from the anonymous behavior that
> mkstemp() previously offered. shm_open() says that it will open an
> existing shared-memory object if that pathname already exists. Isn't
> there a race between one thread doing shm_open() and a different
> thread doing shm_unlink() such that you could accidentally end up with
> two different filedescriptors pointing at the same SHM object?
There's another problem: this path is not unique to the calling user. That
means you need to defend against another user in the system actively trying to
get to your files or forcing you to open the wrong file.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Qt static
On Wednesday, 31 May 2017 04:52:59 PDT Davide wrote: > Hey all > Some times ago I have made a statically built Qt application but I can not > include Wayland platform plugin, because i got the error: > Plugin class name could not be determined for egl-wayland > So if i try to run it on gnome the application switches to XWayland and > xcb. What can I do? Please repost this to the inter...@lists.qt-project.org along with your configure command-line (that's where you select the default plugin) and your application's .pro file. The buildsystem expert does not watch this mailing list. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC weston v2] Add safe_strtoint() helper
On sexta-feira, 15 de julho de 2016 12:39:42 PDT Bryce Harrington wrote: > Adds a safe strtol helper function, modeled loosely after Wayland > scanner's strtouint. This encapsulates the various quirks of strtol > behavior, and streamlines the interface to just handling base-10 numbers > with a simple true/false error indicator and a uint32_t return by > reference. > > Signed-off-by: Bryce Harrington <br...@osg.samsung.com> Looks better. Reviewed-by: Thiago Macieira <thiago.macie...@intel.com> -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC weston] Add strtoint() helper
On quinta-feira, 14 de julho de 2016 13:03:34 PDT Bryce Harrington wrote:
> + ret = strtol(str, , 10);
Here you made a cast from long to int, which may be a loss of data.
ret = strtol("4294967296", , 10);
Will produce no errno since it's in the valid range of long on LP64 systems,
and yet ret = 0.
You should define ret to be a long and then later do:
*value = (int)ret;
if ((long)*value != ret) {
errno = ERANGE;
return false;
}
On systems where long and int are the same (ILP32, LLP64), the conditional is
optimised out of existence by the compiler.
The casts are really optional, but since this in a header, some people may
want to try and use it with annoying compiler options like -Wconversion.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] Remove a wrong closing “extern "C"” in shared/xalloc.c
Em quinta-feira, 14 de julho de 2016, às 01:38:13 PDT, Emmanuel Gil Peyrot escreveu: > > Out of curiosity: why are you compiling C sources as C++? > > > > Is that the Arduino compiler? > > I wasn’t, I just noticed this leftover from a previous copy (likely the > file creation), and just fixed it. > > I don’t have any particular reason to compile C code as C++, as this > might break things in non-obvious ways. Right. It might be a coincidence, because someone was asking on IRC yesterday or the day before about doing exactly that, but I didn't get to ask in time the reason why. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] Remove a wrong closing “extern "C"” in shared/xalloc.c
> -#ifdef __cplusplus > -} > -#endif Out of curiosity: why are you compiling C sources as C++? Is that the Arduino compiler? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 3/6] README: Document versioning scheme, forward compatibility
On segunda-feira, 4 de julho de 2016 15:23:51 PDT Emil Velikov wrote: > +Similar approach is used by ATK, QT and KDE programs/libraries, Qt, with a lowercase t. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2 libinput] Add configure.ac check for static_assert
On segunda-feira, 16 de maio de 2016 13:32:07 PDT Peter Hutterer wrote:
> Part of C11, defined via assert.h.
>
> Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
> ---
> Changes to v1:
> - leave static_assert in place and just check for that in configure
>
> configure.ac | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index 8ddc3b6..8c14efe 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -59,6 +59,10 @@ AC_CHECK_DECL(TFD_CLOEXEC,[],
> AC_CHECK_DECL(CLOCK_MONOTONIC,[],
> [AC_MSG_ERROR("CLOCK_MONOTONIC is needed to compile libinput")],
> [[#include ]])
> +AC_CHECK_DECL(static_assert, [],
> + [AC_DEFINE(static_assert(...), [/* */], [noop static_assert()
You could define it to
#define static_assert(x)((void)sizeof(char[2*!!(x) - 1]))
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: How can an X11 tell it's running in XWayland?
On Friday 31 July 2015 09:59:01 Olivier Fourdan wrote: Hi Jonas, On 31 July 2015 at 09:52, Jonas Ådahl jad...@gmail.com wrote: Might be missing something obvious but shouldn't it be possible to check whether WAYLAND_DISPLAY environment variable is set? Y eap, even simpler! It might have been unset to cause a parent application to start inside X instead of using Wayland. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: launch QT app failed with wayland
On Friday 26 December 2014 17:59:37 Ray·Bloodworth wrote: Is there any possibility that ico-homescreen has setted surface already and the secondary launched app(qt-wayland application) set surface again which conflicts with ico-homescreen? Could you tell me any possibility about this error? I can't. I don't even understand what ico-homescreen is, so I have no clue what you're talking about. I can only act on a backtrace. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: launch QT app failed with wayland
On Thursday 25 December 2014 19:59:18 Ray·Bloodworth wrote: Dec 25 03:49:45 localhost sh[597]: wl_surface@45: error 0: surface-configure already set Dec 25 03:49:45 localhost sh[597]: The Wayland connection experienced a fatal error (Protocol error) It was said something wrong with wayland protocol. Could anyone help me with this issue? Put a breakpoint in any of the two messages and give us a backtrace. Please be sure you're using a wayland-egl plugin compiled with debug symbols so we can get the line numbers from where the error happened in the Qt code. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libinput without udev
On Saturday 06 December 2014 23:33:13 Michael Forney wrote: Currently, libinput is the only system component I would like to use that has a hard libudev dependency, so unless libinput would consider making this optional, I'll have to figure out something else. Do you mind my asking why you want this? Is it because you have a different component that does the same job as udev? Or you're trying to make a very constrained device (RAM and Flash) and you need to make room? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] wl_strtol and wl_strtoul utility functions are added
On Wednesday 15 October 2014 16:16:34 Rémi Denis-Courmont wrote: Le 2014-10-15 16:14, Imran Zaman a écrit : Hi The patch is used to replace strtol and strtoul with wl_strtol and wl_strtoul with inputs and result checks. I don't know where Wayland developers stand on this, but I would rather the client library function calls not clobber errno to zero. There's no other way to detect strto(u)l errors. It returns either 0, LONG_MIN, LONG_MAX or ULONG_MAX for errors, but those are also valid values. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] wl_strtol and wl_strtoul utility functions are added
On Wednesday 15 October 2014 16:14:17 Imran Zaman wrote: Hi The patch is used to replace strtol and strtoul with wl_strtol and wl_strtoul with inputs and result checks. The utility functions are used extensively in wayland and weston so added appropriate input and output checks; test cases are also updated; will push the patch for weston as well. You should use strtol_l and strtoul_l from xlocale.h and pass the C locale. Otherwise, those functions are subject to the locale's definition of a space character. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland compilation problem
On Sunday 17 August 2014 14:43:50 Hongze Zhao wrote: However, I got an error saying No package 'libinput' found Could anyone tell me why this is happening and how to resolve it? Did you compile and install libinput? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: HW key event grabbing on Tizen Wayland
On Tuesday 12 August 2014 01:03:37 yan.w...@linux.intel.com wrote: Hi, All, Today I checked HW key event grabbing on Tizen. In Tizen X (mobile), libslp-utilx package could do this. (E.g. KEY_MENU/POWER/VOLUME_UP/VOLLUME_DOWN/CAMERA...) But how about in Wayland? In Wayland/Weston upstream, I think libinput could do it because I could see KEY_VOLUME_UP/DOWN, KEY_POWER, KEY_BACK, KEY_MENU, ... in it. Is it right? http://cgit.freedesktop.org/wayland/libinput. libinput hasn't been migrated to Tizen Wayland Common/IVI repos so far. Will it be available on Tizen in the future? Thanks. For Wayland, there's no protocol yet for global shortcuts (that I know of). You need to modify the compositor to do it for you. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libinput polling
On Tuesday 15 July 2014 11:51:40 Stefanos A. wrote:
while (!exit) {
int ret = poll(pfd, 1, -1);
if (ret 0) {
// ret is always -1
exit = ret;
}
else {
// never gets here
libinput_dispatch(input_context);
}
}
If I remove 'poll' then I can retrieve input events without any trouble.
Is what I am trying to do supported? If so, what could be the problem? Or,
if not, then is there a supported way to block on libinput events?
What errno are you getting?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Global shortkeys and keyboard focus
On Friday 04 July 2014 14:04:03 Dodier-Lazaro, Steve wrote: The problem is: what are the allowed global shortcuts leaking about users? If it's any key that can be listened to, then we've just gotten ourselves an API for implementing keyloggers. Just because the API and standard allow any key to be requested does not mean that the compositor will honour that request. It can have a rule that limits which shortcut combinations will be allowed. And obviously it should refuse any that conflict with its own shortcuts. But we should have a recommendation to applications as to what modifiers are most likely to be accepted, which in turn means applications should avoid using those key combinations as non- global shortcuts in their UXs. The compositor can also ask the user if it's unsure: confirm you want this application to use this global shortcut. The compositor should remember which applications requested what, so as to avoid conflicts or at least inform the user when that happens. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: xwayland
Em dom 29 jun 2014, às 20:27:22, Pooja Thakoor escreveu: If I am running an X11 application in weston-terminal . How can I be sure about the fact that its running on XWayland? An X11 application should not care that it's on XWayland. For all it should care, it's X, period. How can you be sure that it connected to X, not to Wayland? Well, usually the window decorations will be a tell: if you see the XWayland window decoration, as opposed to whatever passes for decoration in that application's toolkit. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Window placement
Em dom 29 jun 2014, às 17:44:46, Fabrice Rey escreveu: Hi, First thank you for hard work on Wayland/X. As I understand, there is no window placement on the client side in Wayland. Because of that, a desklet application can't place its desklets on the desktop. Currently in Weston, they are automatically placed (randomly, each time at a different position). How is this going to be addressed by Wayland ? By the application and the compositor they're designed for having a specific extension that they use to negotiate the position. The compositor may allow this extension only to known applications it launches. Or maybe not at all: the compositor may want to do that only via plugins running on the compositor itself. Either way, as far as I know, the process is not going to be standardised. Another similar problem is that when receiving a Configure event, the position is not in the event. So for instance in GTK the coordinates are always (0;0). That's expected. Any application knows only about its own windows and never knows about the global position. This is problematic, because the application might want to display things differently depending on where it is. For instance, on right-click, the desklet would pop the menu above it if it's in the bottom half of the screen, and vice-versa. This kind of issue should be solved on the particular use-case, as opposed to telling the application about its global position. This should be solved for all kinds of popups, including menus. It seems that xdg-shell is to bring answers to these kind of desktop-specific problems, so is this planned to be added in this interface ? Fabounet. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Window placement
Em dom 29 jun 2014, às 18:41:51, Fabrice Rey escreveu: Well, a desklet is a desktop widget, for instance a clock or a weather widget. They are a bit particular in the sense that they should be placed at a given position and have no decorations, but that's all, and as far as I know, they have always been implemented using standard normal windows. The idea is that those are tightly coupled with the compositor. There's no need to standardise if they only work with one compositor. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Window placement
Em dom 29 jun 2014, às 18:57:08, Fabrice Rey escreveu: The idea is that those are tightly coupled with the compositor. There's no need to standardise if they only work with one compositor. Google gadget, Screenlet or Cairo-Desklet are not coupled with any Window Manager at the moment, they work on any desktop. So they should also work with any compositor. The current design is that there won't be such a thing. All desktop fixtures will be tightly coupled with the desktop, which in turn means tight coupling with the compositor. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Window placement
Em dom 29 jun 2014, às 19:35:28, Fabrice Rey escreveu: They can't be coupled with the compositor, it would mean that such an application would have to make a plug-in (if it's even possible) for each compositor in the universe. Correct. I'm sure Wayland can be as a good desktop environment as X. That's the goal. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] Add our own version of linux/input.h
Em ter 03 jun 2014, às 16:56:35, Peter Hutterer escreveu: On Mon, Jun 02, 2014 at 10:01:20PM -0700, Thiago Macieira wrote: Em ter 03 jun 2014, às 08:08:15, Peter Hutterer escreveu: Avoids having to #define any values we're trying to use. Header file is from Linux 3.15-rc8. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net Wouldn't this be time as well to start using a different include than linux/input.h? does it matter much? #include linux/input.h makes it clear which header it is, that we ship our own doesn't really change that. I think we should start moving away from a linux/ header. If Wayland gets run on other OS, this header would mean it happens to be the same values, but it's not really a Linux header. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] Add our own version of linux/input.h
Em ter 03 jun 2014, às 08:54:38, Jasper St. Pierre escreveu: I think it should be #include linux/input.h at the very least. a_header_file.h has always meant system library to me. That distinction is blurred when you have third-party libraries. is actually meant for headers in my project because it starts the search from $PWD, whereas starts in the system dirs, if no -I flag is passed. If they are, things change. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] Add our own version of linux/input.h
Em ter 03 jun 2014, às 19:32:06, Peter Hutterer escreveu: The current situation is vague, and this patch probably is not intended to fix that at all, but is there a plan? Or is it expected that other OSs implement their own libinput or something? No, other OS can use libinput, they just need to get evdev into the kernel BSD is already working on this, there's probably options for having a shim between the kernel and userspace but at that point you're probably better off doing it in the kernel directly. Let me extend the question: what happens if one such OS decides to add another constant for something that Linux doesn't have yet. Who decides the value? Should we have H. Peter Anvin resurrect the LANANA so we can have a central registry of codes? Should BSD kernel developers submit Linux kernel patches? Should it be first come, first serve? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] Add our own version of linux/input.h
Em ter 03 jun 2014, às 08:08:15, Peter Hutterer escreveu: Avoids having to #define any values we're trying to use. Header file is from Linux 3.15-rc8. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net Wouldn't this be time as well to start using a different include than linux/input.h? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: help: is there any way to use integer 64 type in protocol?
Em dom 20 abr 2014, às 17:31:48, Jason Ekstrand escreveu: Adding 64-bit types wouldn't be too hard. It would involve adding a int64_t an uint64_t types to wl_argument (I'd call them U and I personally) and adding code throughout libwayland to parse them. In terms of backwards compatibility, it should be fine as long as you make it 100% clear that your new protocol extension uses the new 64bit types and therefore requires the newer libwayland version. That changes the size and alignment of wl_argument on 32-bit platforms. No can do until libwayland 2.0, with a binary compatibility break. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Summary of the security discussions around Wayland and privileged clients
Em qui 20 fev 2014, às 14:04:42, Pekka Paalanen escreveu: FWIW, Weston already does track its children by pid also, so that it can respawn them as needed if they e.g. crash. Some compositors may take advantage of an external process launcher babysitter, like systemd --user. A simpler and more secure solution would be for the compositor to open a UNIX socket to itself before exec'ing the client. Once opened, it should be simpler for the compositor to set the client's capabilities to a flag stored in the structure tracking the client and then execute the client's binary. When running the exec() syscall, all the FDs that have not been opened with the ``O_CLOEXEC`` [flag](http://linux.die.net/man/2/open) will be passed on to the new process. A run-time parameter of the Wayland client could then be used to tell which FD represents the unix socket to the Wayland compositor. An example of such parameter could be ``--wayland-fd=xxx``. The compositor should however be careful it doesn't leak any un-needed FD to the new client. Weston already implements this, and libwayland-client directly supports this with the environment variable WAYLAND_SOCKET. This is documented on wl_display_connect(). That is, all Wayland clients automatically support this, AFAIK. This can also be accomplished by having different mount namespaces, so the socket name is the same but it's not the same actual socket. However, in both cases, this means child processes inherit access to the same privileged socket. Unless you meant that the WAYLAND_SOCKET variable can contain a file descriptor number. Is that the case? In that case, how should the privileged process clear the environment to allow child processes to be launched? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Summary of the security discussions around Wayland and privileged clients
Em qui 20 fev 2014, às 19:56:08, Martin Peres escreveu: Le 20/02/2014 18:42, Thiago Macieira a écrit : Unless you meant that the WAYLAND_SOCKET variable can contain a file descriptor number. Is that the case? In that case, how should the privileged process clear the environment to allow child processes to be launched? Yes, it takes an FD as a parameter (http://code.metager.de/source/xref/freedesktop/wayland/wayland/doc/man/wl_d isplay_connect.xml#63). The environment must be cleared automatically by the kernel because weston must be very careful about opening resources with O_CLOEXEC. I don't think you've understood my question. Suppose Weston is careful already. It creates the socket, ensures it's no O_CLOEXEC, sets WAYLAND_SOCKET and launches the privileged process. Now, the privileged process wants to launch a sub-process. How will the sub- process connect to the compositor? Remember: WAYLAND_SOCKET contains a file descriptor number that isn't available to the child process. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Summary of the security discussions around Wayland and privileged clients
Em qui 20 fev 2014, às 21:31:59, Martin Peres escreveu: Now, the privileged process wants to launch a sub-process. How will the sub- process connect to the compositor? Remember: WAYLAND_SOCKET contains a file descriptor number that isn't available to the child process. Ah, I see. You are suggesting un-setting WAYLAND_SOCKET and using fcntl() to set the socket's fd to CLOEXEC? Setting the socket to O_CLOEXEC is mandatory after you start using it. Two processes cannot write to the same streaming socket file descriptor at the same time. You might be able to do this with a datagram socket, but that's not the case here. It is true that multiple process could end up with the same connection and I didn't think about that. The problem is the same if an application connects to the compositor by itself and then forks. Not sure how the compositor could detect that :s It can't. It will get very confused because two applications with independent states will start stepping on each other's toes. The best outcome of this would be if the compositor detected a problem early on and cut the connection to both. The way I see it, wl_display_connect() must unset the WAYLAND_SOCKET environment variable after getting the file descriptor number and it must set O_CLOEXEC. The socket is not available to child processes. But then the question returns: how do child processes connect to the compositor, if the environment variable was cleared? How do they find the compositor? Solutions: 1) the compositor MUST have a well-known socket name = not an option, since we want to have multiple concurrent compositors 2) wl_display_connect() doesn't clear the environment, but resets it to the actual socket name. It needs to get the socket name from somewhere. = problem: if it's getting the name from the compositor, this may take a few roundtrips and the process may have decided to start the child process 3) use a different environment variable. One variable contains the traditional socket path and the other contains the file descriptor. The latter overrides the former. 4) store both settings in WAYLAND_SOCKET. D-Bus does that: DBUS_SESSION_BUS_ADDRESS can contain multiple addresses, to be attempted in order. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Summary of the security discussions around Wayland and privileged clients
Em qui 20 fev 2014, às 14:34:39, Bill Spitzak escreveu: This makes it impossible for a privileged client to distribute it's privledges to more than one subprocess, or to both itself and a subprocess. I think it's fine. That's hardly a common scenario. To allow distribution of security settings, one could assign them per cgroup. The compositor simply needs to get the information from the caller of what cgroup it is in. Is that information available via SCM_CRED? Alternatively, there could be a shared secret stored in a file for which the file descriptor can be passed. The Wayland compositor can modify the file frequently and request that the client prove its worthiness by reading from the file. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] evdev: set CLOCK_MONOTONIC as the time source
Em qua 19 fev 2014, às 08:47:32, Peter Hutterer escreveu: + libevdev_set_clock_id(device-evdev, CLOCK_MONOTONIC); What happens if the monotonic clock isn't supported? Shouldn't you check that sysconf(_SC_MONOTONIC_CLOCK) 0 ? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH libinput] evdev: set CLOCK_MONOTONIC as the time source
Em ter 18 fev 2014, às 22:33:26, Jasper St. Pierre escreveu: ... and what if it fails? I'd say that requiring CLOCK_MONOTONIC is fine. Are there any popular Linux setups that don't have CLOCK_MONOTONIC? I'm guessing that some weird and niche embedded boards might not support it. Which is a use-case for libinput. However, I'm guessing that it's ok to let the ioctl fail. No need to check if it will fail, simply let it. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] sdk: make C++11 plugins build again
On segunda-feira, 9 de dezembro de 2013 15:57:16, Kristian Høgsberg wrote:
Ugh, ok, sorry. Maybe we need a private header file where we can hide
all our C macros - ARRAY_LENGTH, static_assert, container_of etc.
This poor man's static_assert should work in C99 mode too:
#include assert.h
#if !defined(static_assert) (!defined(__cplusplus) || __cplusplus 201103L)
# define static_assert(cond, msg) enum { \
CONCAT(_static_assert_, __COUNTER__) = sizeof(char[(cond) ? 1 : -1]) \
};
#endif
For proper CONCAT defined elsewhere.
Or, for a public header:
#include assert.h
#if defined(static_assert) || (defined(__cplusplus) __cplusplus = 201103L)
# define wl_static_assert(cond) static_assert(cond, #cond)
#else
# define wl_static_assert(cond) enum { \
CONCAT(_static_assert_, __COUNTER__) = sizeof(char[(cond) ? 1 : -1]) \
};
#endif
For failed assertions, it will produce:
C89, C99, C++98:
error: array size is negative
C11, C++11:
error: static_assert failed fail
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/16] xdg-shell protocol, implementation and port of toytoolkit.
On quarta-feira, 27 de novembro de 2013 15:50:16, Rafael Antognolli wrote: As discussed previously, this patch series adds the xdg-shell protocol, its implementation on weston, and the client implementation on toytoolkit. Nice to see this coming. Thanks, Rafael and Jasper! -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Thoughts about decoration information in the xdg_shell
On segunda-feira, 18 de novembro de 2013 08:36:48, Martin Gräßlin wrote: Such a protocol would make runtime switching impossible, wouldn't it? Now you draw, now I draw ? Yes. That's a really important use case for us to turn a tablet into a desktop and vice versa. I don't think so. You can implement tablet-to-desktop and vice-versa without changing roles. In fact, I recommend you go for all-client decoration. Just negotiate *which* decoration to display. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Thoughts about decoration information in the xdg_shell
On segunda-feira, 18 de novembro de 2013 10:31:15, Bill Spitzak wrote: So here is even simpler: - All clients MUST be able to draw decorations - The compositor, as part of configure events, can tell the client to not draw decorations. That also works and it's even simpler. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Thoughts about decoration information in the xdg_shell
On segunda-feira, 18 de novembro de 2013 10:35:58, Bill Spitzak wrote: I also want to put in a very strong vote against any kind of idea that a client can prefer SSD, as is being continuously suggested here with comments like this: Thiago Macieira wrote: A client MAY ask the compositor to draw decorations. This is going to be used as an excuse by clients to *require* SSD. A client may ask, but the server may not support the extension. If it doesn't, then it won't reply and then the client will have to draw its decoration. But your other suggestion that the compositor tells clients not to draw is even better. The only detail is that this extension doesn't exist yet, so the compositor needs to check whether the client acknowledged the message. If it didn't, then the compositor must assume the client is decorating itself. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [xkbcommon] Use an integer type for modifiers bit mask.
On sexta-feira, 4 de outubro de 2013 09:09:32, Wander Lairson Costa wrote: The issued raised when I took code from window.c in the weston clients: mask = xkb_state_serialize_mods(input-xkb.state, XKB_STATE_DEPRESSED | XKB_STATE_LATCHED); g++ gave me a build error because I was passing an integer to enum parameter. C++ is a bit more nit-picky than C regarding implicit conversions. Therefore I had to use a cast. Like you said, it's window.c. Why are you copy pasting C code into a C++ file? With the ABI that GCC uses, it's always at least 4 bytes. Personally, I don't like enum's in the ABI at all, because according to C/C++ standards, the compiler is free to choose whatever type it likes, and indeed I had problems with that in the past. C++11 fixed that [1]. But nevermind. We're not relying on the ABI. I said The enum must be backed by an integer with at least as many bits as the enum possesses.. If you cast back from an int that contains one of the enum values or an OR combination of enum values, it *will* fit. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Qt 5 on Wayland support for QtQuick 1.1?
On terça-feira, 9 de julho de 2013 10.18.59, Carlos Gomez, HCL America wrote: Hello - Does the Qt 5 on Wayland project provide backwards compatibility to QML/QtQuick 1.1 ? Yes. If you can display a pixel on screen with Qt 5 on Wayland, Qt Quick 1.1 is supported. It can run with the raster backend. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston sdk v2 1/8] weston.pc: Add dependencies for pixman-1 and xkbcommon
On quinta-feira, 4 de julho de 2013 18.35.16, sardemff7+wayl...@sardemff7.net wrote: Suppose that our headers #include headers from a project whose headers aren't usually in /usr/include (that is, they require -I). In order for our users' applications to build, they need to add those -I as well. The Requires is what tells pkg-config to add them. Requires.private too. See below. What's more, even if the include paths are not an issue, the linking could be. Since we included some third party API in our API, it's conceivable that users might need to call functions in those libraries. If that happens, then user applications must also link directly to the libraries, not indirectly only. And they must link directly! That is the proper way to do that. I partially agree. If I know in my API that I am using both libs X and Y, I should tell my buildsystem so. But there are cases when I don't know of the indirect dependency. I'm using X, and I'm not using any of Y's API. Yet to compile my application, X requires Y's headers. That means X's .pc file should declare it depends non-privately on Y. This is especially the case in C++, when base classes, operators, constructors and other things can hide from you the fact that you're using some other library. A plugin is using libxkbcommon for a feature, but provides several more. Weston is build with libxkbcommon support. All is fine. Yes. Now, the same plugin is build against a non-libxkbcommon Weston (this is the now-possible case): it will break badly. Explicit usage is the way. Period. Agreed: the plugin should declare explicitly. If a project uses intentionally a library, it should declare explicitly the dependency. But I also disagree: if libweston's public API headers include unconditionally some other library's headers, libweston's .pc file should declare the public dependency. Otherwise, no plugin will compile. Of course, there's also a grey area: an optional feature. Suppose that there's exactly one Weston header that requires xkbcommon and that header is not included by any other: weston-xkbcommon.h. In that case, anyone who uses that header is intentionally depending on xkbcommon. So in that case, weston.pc doesn't declare the public Requires. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Qt 4.8 on Wayland ?
On segunda-feira, 17 de junho de 2013 12.14.39, Abhijit Potnis wrote: :). I know Qt5.0 is already old ! It's my employers client who has this requirement for Qt 4.8 ! That's exactly the problem. Are you modifying an existing application? It's probably an application using Qt for X11 or Qt for Embedded Linux. To run on Qt for QPA, you'll need to do some porting, albeit quite minimal. The biggest parts will be the windowing system support, for which no one will be able to offer help. The effort might be equivalent to porting to Qt 5. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] window: avoid a gcc warning in buffer release handler
On quarta-feira, 22 de maio de 2013 10.20.05, ppaala...@gmail.com wrote: Apparently some compilers complain about set but not used variables 'available' and 'bufs', but I don't get the warning. Still, separate the debugging code from shm_surface_buffer_release(), so that we only compute 'bufs' when it is printed. This should fix the warnings Set-but-unused is a new warning in GCC 4.7 and, as most warnings of its type, sometimes it triggers only in release (optimised) mode. If you're building with -O0 or an older GCC, you might not have seen it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: protocol questions
On quarta-feira, 3 de abril de 2013 12.43.35, Kristian Høgsberg wrote: But the client may still want to popup a grabbing window (e.g. system-tray menu) in response to other event (e.g. dbus event) indirectly caused (handler in another process) by the user input. I can't think of anything that does this in any desktop environment I've ever seen. The only case I currently have of something grabbing my X server is the GPG Agent pinentry program. But in that case, we've discussed in the past that we actually want to solve this problem differently: inform the compositor that this is a password / input-sensitive dialog and let the compositor handle it as it will. Anything else that pops up in my desktop won't get focus due to focus-stealing prevention anyway. The one thing that needs to break out of that are out-of-process windows that still logically belong to the same application. KDE, for example, does that for the KWallet password but also for those file transfer dialogs, showing progress. You can also easily go further, like having a separate settings application for configuring an application, but launched from inside the application. Do we have a defined way of transferring focus and modality, enforcing stacking order? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: protocol questions
On sábado, 30 de março de 2013 09.34.24, Matthias Clasen wrote: - Various input events have a time field. The spec doesn't really say anything about this. What is it good for, and what units are these - monotonic time ? Monotonic (ideally) time in an undefined domain, i.e. they're only meaningful on relation to each other. What can you do with them ? For the use case that Giulio mentioned (double-click detection), I'd need to know at least if the difference between two times is seconds or milliseconds or microseconds... The protocol needs to specify the unit. It can't be dependent on the device driver, that makes no sense. If it's in milliseconds, it will overflow every 49.7 days. If it's microseconds, it will overflow every 71.6 minutes. It also needs to specify which timestamps are in the same time domain. Can two timestamps be compared to each other only if: - they are in the same input device (same mouse, same keyboard), but not across devices - they are in the same seat, but not across seats - they are in input event messages, but not other types of messages that carry timestamps - no restriction For example, imagine the case of trying to ensure that a Ctrl key was pressed before a mouse click happened, after the events were plucked out of the event stream. Or is there another, recommended way of doing that, such as by using the serials? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: protocol questions
On sábado, 30 de março de 2013 17.52.33, Nick Kisialiou wrote: What about long int type to store the time stamps? Even in microseconds it will take longer than 100 years to overflow 2^63. That requires changing the protocol. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] server: use void* instead of function pointer for wl_object.implementation
On quinta-feira, 28 de março de 2013 14.55.51, Giulio Camuffo wrote:
use a union { void *obj; void (* const *func)(); }; in wl_resource_init()
in wayland-server.h to convert between the two (really ugly imho) or
uninline wl_resource_init() and put the implementation somewhere the c++
compiler doesn't see.
FYI but it probably does NOT affect Wayland:
The union conversion trick is undefined behaviour in C++98 and C99. Both
standards say that it is undefined to read from an union member that was not
the last one stored. This is especially important if you use the store-A
modify-B read-A pattern, as the compiler might optimise the modification out of
existence.
GCC hardcodes the behaviour that reading from a member that was not the last
stored means reinterpreting the bits of the union. I believe other GCC-
compatible compilers (Clang and Intel Compiler) do the same. This behaviour
was also specified for C++11. I haven't checked if C11 also has it.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Helping in reviewing
On quarta-feira, 27 de março de 2013 14.15.14, Siddharth Heroor wrote: Recent circumstances have shown that patch reviewing in Wayland and Weston is becoming a bottleneck for development (at least, it is perceived to be). This email is intended to begin addressing that. Would setting patchwork help in improving the management of the patch queue? It might. But again, this is a decision that needs to come from those who review. The project needs a tool that makes them comfortable and efficient. I'm not such a person, so I can't make a recommendation. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Helping in reviewing
Recent circumstances have shown that patch reviewing in Wayland and Weston is becoming a bottleneck for development (at least, it is perceived to be). This email is intended to begin addressing that. TL;DR: if you want to help, the best thing you can do right now is review other people's contributions. Longer: Correct or not, the perception is that only Kristian has the authority to review and accept patches into Wayland and Weston. For that reason, it seems that no one else reviews patches, leaving them all to Kristian. In turn, that means Kristian has a lot of reviews to do, in addition to writing code. That does not scale. Everyone can help in reviewing, from the newest member of the community to the oldest. Reviewing is basically two separate operations: (1) technical (objective) review: - is the code correct? - does it compile? Does it introduce new bugs? - does it fix the problem that it proposed to fix? Or does it successfully implement the feature it proposed to implement? - will it pose future problems, architecturally, security-wise, etc.? - does it have unit tests? Is it documenting the API? - is the code style correct? - ... (2) subjective review: - does this solution belong in Wayland or Weston? - is it in scope for the project? - is it the right solution for the problem? - is the API easy to use? Not confusing? - is the code readable, and properly commented? - is this the right time for this? Is this the best use of resources? - ... In both cases, the more experience you have in reviewing, the better the review will be and the easier it will be to review. However, for a new contributor, starting with the technical is easier, since it's objective. In time, you'll learn how to do the subjective review too. Also, don't be afraid of doing bad reviews. Other people will review the same contribution and review reviews. If a mistake is found, everyone learns. For the subjective review, there is really no right or wrong, but a consensus of the community. So speak up. Especially, speak up if the patch looks good. If you think it passes the review criteria, *say so*. Reply to the email saying This looks good, Ship it! or Awesome, thanks! (BTW, praise goes a long way towards making people feel welcome). Kristian and other designated people with repository access will gladly accept those reviews and apply the contribution to the codebase. Of course, they reserve the right to re-review and point out if there were any problems. But just like above, if that happens, everyone learns. = Why you should do this? Well, if you're here, it's because you want Wayland and/or Weston to succeed. If you contribute a bit of your time and expertise, you're helping the project achieve that goal. If you have patches you have submitted yourself, by reviewing you free up the time from other reviewers, increasing the chances that your contribution will be dealt with sooner. Think also of this as tit-for-tat: if you want code reviewed, review code too. You'll also gain experience in reviewing. You'll become more familiar with the codebase. That might come in very handy if you're doing this as part of some company project. And you'll gain merit in the project. The more you contribute (in reviews or in code, but those go hand-in-hand), the more you'll be respected and the more your own opinions will be listened to. This is important when it comes to consensus-building and decision-making: Open Source Projects are not democracies and definitely not tyrannies. They are meritocracies, where those who have contributed the most get to make decisions. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Helping in reviewing
On terça-feira, 26 de março de 2013 19.32.54, Bernhard Friedreich wrote: What I've been wondering lately (and also in the light of recent events) is if there is a specific reason why there's no CI (Jenkins?) and/or reviewboard system (Gerrit?). Is it because reviewing patches on the maillinglist gathers more feedback (out of previous experiences) or just because it is more comfortable for you? Is it more comfortable? I guess some system like gerrit scales better.. Or is it because no one set up something yet? Has there been thought about setting up a code quality system? For example sonar is very good at those things and is widely used - at least in the java world. Didn't try it with C/C++ yet.. This is really up to the people doing reviews. They have to choose a method that is most comfortable to them. In this aspect, convenience for the casual drive-by-submitter is completely trumped by convenience for the reviewer. I can't make that decision. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Helping in reviewing
On terça-feira, 26 de março de 2013 12.50.46, Nick Kisialiou wrote: I'm not a Wayland developer but I suspect it wouldn't be wise to lump Wayland (protocol) and Weston (compositor) together on this issue. Wayland: I'm not sure why it is a problem that Wayland patches take time to be merged. Isn't it the whole point of any protocol to be as stable as possible? If the protocol is constantly in some fluid experimental state then toolkit developers have no incentive to port their code. Outside of that, anyone who wants to do their experiments can easily do so in their local sandbox -- the code is open source after all. Weston: IMHO, Weston patches don't need to go through the same rigorous review process. I don't see a difference in this issue. I'm asking that people step up and review. That does not mean that we should start accepting sloppy reviews. You're right, though, that Wayland changes require more attention and a more thorough analysis. That's part of the review process. And yes, it will require people with more experience to do those reviews. The catch is that we'll never get those people *unless* they start reviewing now. So whenever you see a change that you think you can provide input on, do so. If you don't feel like saying it's completely fine, say so too. The initial review you provide on simpler things (coding style, thread-safety, etc.) is already helping. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] client: Add acquire-fd API to avoid requiring a polling main thread
On segunda-feira, 25 de março de 2013 13.42.31, Kristian Høgsberg wrote:
which returns the display fd and blocks any thread trying to read from
the fd. Calling wl_display_dispatch() will read events, release the fd
and the dispatch events. Alternatively, if after acquiring and polling
the fd, a thread decides to not call wl_display_dispatch() after all,
the fd can be released by calling wl_display_release_fd(). This is
typically useful when poll returns without data on the fd, eg in case of
timeout.
Wouldn't it be better to require calling display_release in all cases? That
is, avoid the magic of releasing the file descriptor inside
wl_display_dispatch?
This would add support for dispatching more than once while in a consistent
state.
/** \endcond */
@@ -518,6 +529,10 @@ wl_display_connect_to_fd(int fd)
wl_event_queue_init(display-queue, display);
wl_list_init(display-event_queue_list);
pthread_mutex_init(display-mutex, NULL);
+ pthread_cond_init(display-reader_cond, NULL);
+ pthread_cond_init(display-pipe_cond, NULL);
+ display-reader_state = LEGACY_READER;
+ display-reader = pthread_self();
wl_map_insert_new(display-objects, WL_MAP_CLIENT_SIDE, NULL);
@@ -540,9 +555,118 @@ wl_display_connect_to_fd(int fd)
return NULL;
}
+ if (pipe2(display-reader_pipe, O_CLOEXEC) == -1) {
+ wl_connection_destroy(display-connection);
+ wl_map_release(display-objects);
+ close(display-fd);
+ free(display);
Need to pthread_cond_destroy the two condition variables here.
+ * by calling wl_display_dispatch(). Simplified, we have:
+ *
+ * wl_display_dispatch_pending(display);
+ * poll(fds, nfds, -1);
+ * wl_display_dispatch(display);
+ *
+ * The other race is immediately after poll(), where another thread
+ * could preempt and read events before the main thread calls
+ * wl_display_dispatch(). This call now blocks and starves the other
+ * fds in the event loop.
This one could be solved by calling wl_dispatch_pending in all cases, couldn't
it?
+WL_EXPORT int
+wl_display_acquire_fd(struct wl_display *display)
+{
+ char c = 0;
+ int old_state;
+
+ pthread_mutex_lock(display-mutex);
+
+ if (display-reader_state == LOCKED_READER
+ !pthread_equal(display-reader, pthread_self())) {
+ errno = EBUSY;
+ pthread_mutex_unlock(display-mutex);
+ return -1;
Do we need the pthread_equal check? Just let it return EBUSY if someone tries
to acquire twice in the same thread. You're not counting the number of locks,
so this could lead to an unexpected releasing if someone is nesting acquires.
+WL_EXPORT void
+wl_display_release_fd(struct wl_display *display)
+{
+ pthread_mutex_lock(display-mutex);
+
+ if (display-reader_state != LOCKED_READER ||
+ !pthread_equal(display-reader, pthread_self())) {
+ pthread_mutex_unlock(display-mutex);
+ return;
+ }
Ditto. If someone releases without acquiring (or releases from the wrong
thread), their code is wrong.
@@ -597,6 +721,8 @@ wl_display_disconnect(struct wl_display *display)
pthread_mutex_destroy(display-mutex);
if (display-fd 0)
close(display-fd);
+ close(display-reader_pipe[0]);
+ close(display-reader_pipe[1]);
Missing pthread_cond_destroy here too.
@@ -847,45 +973,105 @@ dispatch_event(struct wl_display *display, struct
wl_event_queue *queue) }
static int
-dispatch_queue(struct wl_display *display,
-struct wl_event_queue *queue, int block)
+read_events(struct wl_display *display, struct wl_event_queue *queue)
{
- int len, size, count, ret;
-
- pthread_mutex_lock(display-mutex);
-
- if (display-last_error)
- goto err_unlock;
+ struct pollfd pfd[2];
+ int len, size, ret;
+ char c;
+
+ if (display-reader_state == NO_READER) {
+ /* A thread gets here when it's the first reader to
+ * try to read and there's LOCKED_READER. We set
and there's [no] LOCKED_READER, I guess?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] client: Add acquire-fd API to avoid requiring a polling main thread
On segunda-feira, 25 de março de 2013 19.49.32, Uli Schlachter wrote:
So wl_display_acquire_fd() would do:
if (old_state == VOLUNTEER_READER) {
write(display-reader_pipe[1], c, 1);
pthread_cond_wait(display-pipe_cond, display-mutex);
read(display-reader_pipe[0], c, 1);
}
There might be a priority inversion / resource starvation problem here.
When the other thread returns to its caller, that caller may call the dispatch
function again and cause it to poll(2) again, before the pipe is emptied.
Since the pipe is still readable, poll(2) will return immediately and it
returns to the caller. Nothing changed since the last time, so the caller may
again cause it to dispatch.
That other thread will be always in runnable state and will be at 100% CPU
usage (busy-loop), waiting for this (suspended) thread to empty the pipe. The
OS may take some time to wake it up from cond_wait. Meanwhile, we're burning
CPU and consuming battery.
Unless there's something before the call to poll(2) that will prevent it from
happening in the first place. I have to confess I have not yet understood this
problem to confirm or deny that.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
On segunda-feira, 25 de março de 2013 14.45.21, Scott Moreau wrote: Northfield stands on the shoulders of giants, years worth of work and history to get to the point where we are today. It has been some 8 years since compiz has exposed these many restrictions found in X protocol. We want certain effects to be readily possible and are not inherently restricted by certain caveats of the display server protocol. I expect that wayland core protocol will be added to support the basic functionalities expected as part of todays Linux Desktop. I believe that there wont be any problems with this particular effect and others. However, I want to make absolutely sure of that. Scott, What we're asking is that you avoid forking Wayland at all. Don't change the library, don't change the default extensions (including wl_shell), don't add new default extensions. You said you want to avoid incompatible changes: well, avoiding the fork also avoids the temptation. Try to do your changes in a different extension. Copy the current wl_shell into a new one and modify it to your heart's desire. If, at the end of your experiment, you conclude that the current wl_shell is flawed by design, then Wayland should deprecate it and adopt yours. On the other hand, if we conclude that your improvements can be added incrementally, we can simply do exactly that. I'll ping you on IRC to discuss this. Several people have asked you to do it and you have either missed the point or failed to explain to us why the fork is necessary. PS: compiz is also a bad example. It might have been a great experiment and resulted in improvements in most existing WMs, but it was a horrible WM. It had bugs with its core WM functionality that went unfixed for years. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiz is Dead - Beryl Lives Again? Enter - Northfield/Norwood
On segunda-feira, 25 de março de 2013 15.12.47, Scott Moreau wrote: Try to do your changes in a different extension. Copy the current wl_shell into a new one and modify it to your heart's desire. If, at the end of your experiment, you conclude that the current wl_shell is flawed by design, then Wayland should deprecate it and adopt yours. On the other hand, if we conclude that your improvements can be added incrementally, we can simply do exactly that. This sounds great but this is not the solution I have come up with. Ok, understood. Can you tell us why your solution is better than the above? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Support XDG_RUNTIME_DIR being unset
On segunda-feira, 11 de março de 2013 18.43.07, Emilio Pozuelo Monfort wrote: Debian doesn't by default (you can use systemd or upstart, but sysvinit is the default init system). Probably others, as well as *BSDs (some people are interested in porting wayland to them). That has nothing to do with systemd or upstart or sysvinit. Simply set a proper variable on /etc/profile pointing to a proper location, one that the distribution knows to meet the requirements. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: 1.0 Branch created
On sexta-feira, 9 de novembro de 2012 10.37.06, Kristian Høgsberg wrote: I've created 1.0 branches in the wayland and weston repos. I found it confusing the use the 'master' and 'next' terminology when replying to patch emails and being able to just say 'commited to 1.0' is a lot clearer than saying 'committed to master' and then wonder whether 'master' is the feature branch or the stable branch. It's a matter of taste. But here's a little suggestion from me: Some projects prefer the master branch be the default check-out and contain the latest version that regular people should use. The question is then what is regular. If you're expecting a lot of newcomers to clone, the default branch should be the stable version. If you're expecting them to be developers, it should be the development branch. For example, the Linux kernel and Git itself publicise their stable repositories (linux-stable.git, git.git), where the master branch is the default and contains the latest stable. On the other hand, GNOME and KDE devs have their development branches in master (the default), which is closer to past Subversion and CVS usage. One thing I no longer recommend is having the version number as the branch. I recommend instead to have semantic names like next or stable. This way, once you check out the branch that is right for you, you only ever need to run git pull, even for people inexperienced in Git. See my proposals for Qt in [1] [2] [3], which we're adopting. [1] http://lists.qt- project.org/pipermail/development/attachments/20120927/13b4a7ef/attachment-0006.png [2] http://lists.qt- project.org/pipermail/development/attachments/20120927/13b4a7ef/attachment-0007.png [3] http://lists.qt-project.org/pipermail/development/2012- September/006691.html [or with everything in one: http://permalink.gmane.org/gmane.comp.lib.qt.devel/6738 ] -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: new xwayland protocol
On sexta-feira, 14 de setembro de 2012 10.07.38, dar...@chaosreigns.com wrote: On 09/14, Pekka Paalanen wrote: Apparently you have forgot all about, say, dome projectors or virtual displays, where the output is a half sphere. Good luck mapping Cartesian global coordinates there in any meaningful way. What coordinate system does that use, if not cartesian? Considering it's half a sphere, I'd guess it's spherical surface coordinates (just θ and φ). :-) -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Q: xwayland overt Qt-compositor?
On terça-feira, 21 de agosto de 2012 10.07.57, dar...@chaosreigns.com wrote: I am unclear of the Qt/X/Weston/Wayland interoperability. Does the weston compositor work with Qt5 apps? Can the Qt5-compositor run the Weston apps? I haven't tested them lately, but I believe the answers should be yes. If, by Weston apps, you mean Wayland apps, yes. There's nothing special about them. Will the Qt compositor host the xwayland server? I haven't heard. I'm still not entirely sure what the relationship between xwayland and different compositors is expected to be. It may be better to ask the Qt folks. #qt-labs on irc.freenode.net in particular. I'm not sure which mailing list is most appropriate. That would be developm...@qt-project.org, since Wayland support and the compositors are really in development right now. Qt apps don't even know which backend they're using, it's all nice and Qt apps _can_ know the backend if they really want to. http://qt-project.org/doc/qt-5.0/qguiapplication.html#platformName-prop But applications should be written not to depend on the platform. magical. And last time I tested, the Qt5 apps worked with the weston compositor, but the Qt5 demo wayland compositors crashed, but were expected to work with wayland apps. I suspect xwayland stuff hasn't been handled with the Qt compositors. The compositors are all experimental and just examples of what can be done. They are not meant to be used in a production environment. Running Weston is recommended. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] use magic wl_fixed_t to/from double only on x86-64
On quarta-feira, 16 de maio de 2012 13.34.42, Pavel Vasin wrote: on x86: benchmarked magic: 14.048889885s benchmarked div:5.426952392s benchmarked mul:4.034106976s on x86-64: benchmarked magic: 2.467789582s benchmarked div:9.748067755s benchmarked mul:8.665307997s Those are interesting numbers. The magic I understand being different, since on x86 it's using two 32-bit registers and needs to do some magic on the magic to support the 64-bit operation. The Intel optimisation manual says that the ADC (add with carry) instruction isn't the fastest. However, the div and mul are much more interesting. Those ought to be the same, so I am actually wondering how it is possible that the div and mul on x86-64 can be so slow. Did you compile your 32-bit code with -mfpmath=sse? If not, could you try and post the results again? I'd be quite surprised if it turned out that the x87 operations are faster than the SSE ones, but that's what your numbers show. Either way, the x86 div and mul are still slower than the x86-64 magic, but faster than the x86 magic, so it looks like your patch is correct, given your benchmarks. It might be that other 64-bit platforms have similar benefits, though, in which case the if should be defined(__x86_64__) || defined(__LP64__). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] use magic wl_fixed_t to/from double only on x86-64
On quarta-feira, 16 de maio de 2012 11.20.03, Bill Spitzak wrote: Thiago Macieira wrote: However, the div and mul are much more interesting. Those ought to be the same, so I am actually wondering how it is possible that the div and mul on x86-64 can be so slow. Divide by x and multiply by 1/x are not exactly the same because 1/x may not be exactly represented in the floating point format. So I think this is the reason the compiler is not producing the optimization. Though 1/256 can be represented exactly so it does not apply to this specific case. Please note that it's the same code, same compiler, the difference is whether it's using x87 or SSE for the floating point math. Somehow, the x87 code is faster, which is counter-intuitive. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PULL wayland] fd leak checks and a socket fallback
On segunda-feira, 23 de abril de 2012 11.22.16, Pekka Paalanen wrote: PS: if you're reading this and you want to run Wayland on your non-Linux system, you should also add those to your OS. Yesterday. Hi Thiago, you speak with the voice of reason. Unfortunately, I doubt reason or sanity is something to be strongly associated with Android. I'm not ready take on such battle for now. Well, they said that bionic was a stripped-down version of libc, sometimes deviating from POSIX, and it would only be used to support Android's own needs. However, since Android is heavily based on Java, which in turn encourages the use of threads for everything, I really can't see how they can write the C backends for those libraries without the thread-safe system calls. In fact, I was quite surprised no one had thought of that before Ulrich Drepper came up with them back in 2008. In any case, while on Linux, the constants are cross-architecture, so you can #define them if they weren't before. If the libc doesn't provide the system calls, there are workarounds: 1) open socket - no new system call required, just a new constant 2) dup3 - just use F_DUPFD_CLOEXEC, which we do in Wayland 3) pipe2, accept4, eventfd2, epoll_create1, etc. - can use syscall: syscall(__NR_accept4, fd, addr, addrlen, SOCK_CLOEXEC); Option 3 is unavailable if bionic doesn't provide the syscall(3) function. I'd say that writing assembly to make the system call is above the pain threshold for solving this particular issue. In that case, we can point the finger at them and say it's not thread-safe and it's entirely your fault. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PULL wayland] fd leak checks and a socket fallback
On sexta-feira, 20 de abril de 2012 16.46.52, Pekka Paalanen wrote: Hi Kristian, finally I am getting the test framework up for my OS wrappers. I added automatic fd leak checks, and helpers for checking fd leaks through exec(). They have their sanity tests. The other feature in this series is the fallback for socket() and SOCK_CLOEXEC flag, which is not supported in Bionic. It comes with tests for both normal use and a forced fallback hack. If this series looks acceptable, I can clean up the rest of my OS wrappers and write tests for them. Can I urge you to try the following first: #ifndef SOCK_CLOEXEC # define SOCK_CLOEXEC 0200 #endif And tell the bionic maintainers that this macro and O_CLOEXEC and other similar system calls (pipe2, dup3, accept4) are a must in any thread-safe software. We really need them. The accept4 system call, the last one of them to be introduced, came about in kernel 2.6.28, the other ones in 2.6.27. PS: if you're reading this and you want to run Wayland on your non-Linux system, you should also add those to your OS. Yesterday. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: About decorations in Unity
On terça-feira, 27 de março de 2012 22.32.13, Damián Nohales wrote: El 27/03/12 19:24, Thiago Macieira escribió: I guess the toolkits would simply forego drawing the decoration when it detects that the window is maximised. But this behaviour is not shell dependent? for example, in KDE shell the windows normally does not stop to print windows decoration when its are maximized. How clients know when forego drawing decorations, don't they need some compositor talk? I think you're missing the fact that the clients run decorations that are specific to the environment they're running, which in turn known when to decorate and when not to. For example, if you're running in KDE, the KDE decorations will draw a title bar all the time and borders only when not maximised. If you're on Unity, the Unity decorations in your toolkit will draw the decoration only when not maximised. If needed, the toolkits will communicate with the Unity compositor via a private interface so that some merging of information can be done. Note the obvious conclusion that this requires each toolkit to have client- side decorations for each compositor type. However, this is no more different than each toolkit having widget styles that are alike. If you run an application with a toolkit without such support or with somehow wrong settings, it will look different anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Why the GTK+ wayland backend can't be enabled in linux distros, at all
On terça-feira, 27 de março de 2012 18.00.55, Pierre-Loup A. Griffais wrote: Hi Thiago, Thanks for your interest in the NVIDIA driver; please allow me to try to clarify the situation. You're right that we're not building with -fPIC for performance reasons, but that only applies to the x86 platform. No text relocations should be present in our x86_64 libraries thanks to PIC being free on that platform. Indeed, it had to be the case because there is no linker option to generate text relocations in position-independent code for x86-64. For x86, the absence of -fPIC means text relocations but still allows for position-independence. Still, the OP did not say whether the issue was on x86 or not. There exists a utility called 'prelink' that can be used to pro-actively relocate shared objects on the system (or a single shared object to an arbitrary base address), removing the need for the loader to apply relocations if used properly. Prelinking libnvidia-glcore at a fixed, free address allows memory that would otherwise by dirtied by the loader when relocating to remain shared cleanly between processes. Last I checked prelinking the NVidia GL libraries, there were two problems: 1) prelink refused to work on ELF modules with text relocations, which excluded the NVidia libs outright 2) even for modules that were prelinked, the pages weren't shared when loaded. Now this might be a problem in my measurement or because the binaries I tested with did not have pagefuls of GNU_RELRO. Prelinking helps with load time processing, but not with reducing memory footprint. However, the linux ELF loader currently has a bug that causes the second type of relocation to be overwritten even if prelink had already initialized them to the correct value. This causes the memory in the relocation sections to get dirtied without anything being changed, which contradicts our goal. That might explain my results too. Attached is a proof-of-concept patch which fixes this issue for the x86_64 Linux ELF loader. By both applying this patch to the loader and prelinking libnvidia-glcore.so, distros can reduce the memory overhead of linking an application against the NVIDIA libGL to just a few kB: Interesting. Those are very good results. Can you provide the same results when two applications are running? Our hope is that those 6544 kB of Private_Clean (which are sharable) become actually shared and move to Shared_Clean. Has this patch been submitted to the glibc folks? They have just had a change of governance. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Why the GTK+ wayland backend can't be enabled in linux distros, at all
On domingo, 18 de março de 2012 17.07.11, dar...@chaosreigns.com wrote: B) Get the Nvidia proprietary driver to reduce memory consumption. I haven't touched this one. All I have found is linux-b...@nvidia.com mentioned on http://www.nvidia.com/object/linux_display_ia32_169.09.html The NVidia GL libraries are notorious for being linked with text relocations. Each program that so much as loads that libGL gets 10-15 MB more memory usage, from start. NVidia knows about this and will not do anything. Enabling -fPIC does cause a performance regression because of indirect memory accesses and by reserving one register. Simply adjust your expectations: anyone using NVidia proprietary drivers will have to deal with this issue. So discount the 10-15 MB increased memory usage per application using libGL and check your numbers again. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Catastrophic blocking
On quarta-feira, 29 de fevereiro de 2012 11.50.10, Kristian Hoegsberg wrote: which handles the problem you hit. The connection code polls for writable just fine and only writes when the fd returns EPOLLOUT. Except in the above case, which is where it typically happens. When the protocol buffer is full, we write without checking for writable, and after a while that hangs. One option would be to just kill the client if the protocol buffer overflows, but that doesn't leave the client a lot of rope. Also, aparently an fd can be spuriously writable, that is, even if we get EPOLLOUT, writing to it may still block. That sure seems like a bug to me, but if we pass MSG_DONTWAIT to sendmsg we guard against that and can fill up the kernel buffer before we kill the client. MSG_DONTWAIT is Linux-specific. Why isn't the socket in non-blocking mode in the first place? Is there any problem with that? I know there are other non-standard flags too, but they can all be handled by setting to 0 (MSG_NOSIGNAL, MSG_CMSG_CLOEXEC) and taking further action. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
