Re: [e-users] Wayland problems
On Sat, 12 Jan 2019 15:44:11 -0500 Conrad Knight said: > On Sat, Jan 12, 2019 at 9:48 AM Carsten Haitzler wrote: > it's been working a charm for me for months now... :) little > things here and > there have been fixed, but it's pretty much good. > > Ok, got it working :) > > I now have a build that will run under either Wayland or Xorg, based > on which session i choose to log in. This is based on the efl and > enlightenment from git, using the efl configuration parameters from > that AUR archive (without any of the disabler ones set). > > However, now i still have my original two problems: an extra cursor > image in the middle of the screen, and no control over the window > borders. In fact, under the window menu, the "border" entry is > missing. If i go into "locks", "do not allow border change" is > checked. Unchecking it brings back the "border" entry, but top option, > "select border style", is missing. borders in wayland are not provided by the wm - they are CSD (client side decorations). at least wayland clients do CSD. x apps will get a border like ye olde x, so don't expect getting e's border things to work in wayland - they are not meant or designed to. :) well not with wayland clients... > The ghost cursor appears where the cursor was positioned on the login > screen before hitting enter after typing my password. If i switch back > to gdm's login screen, move the cursor around, then switch back, the > ghost cursor is in the new position. I can get rid of it by switching > to a vt that doesn't have this cursor and then back to e (wayland). > This may be a gdm3 problem, but a gnome wayland session doesn't show > it. right now i'm wondering if this is a driver issue with nouveau+kms/drm. not specifically the gl stack bits but basic plane/buffer handling? i don't see this on my other devices... :( > The window border problem is the bigger issue: e seems to draw borders > whether or not windows should have them, and there doesn't seem to be > any way to remove them. > > Thanks, > -Conrad. > > -- > Shine like thunder > Cry like rain > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Wayland problems
On 1/12/19 9:44 PM, Conrad Knight wrote: However, now i still have my original two problems: an extra cursor image in the middle of the screen, and no control over the window borders. In fact, under the window menu, the "border" entry is missing. If i go into "locks", "do not allow border change" is checked. Unchecking it brings back the "border" entry, but top option, "select border style", is missing. The ghost cursor appears where the cursor was positioned on the login screen before hitting enter after typing my password. If i switch back to gdm's login screen, move the cursor around, then switch back, the ghost cursor is in the new position. I can get rid of it by switching to a vt that doesn't have this cursor and then back to e (wayland). This may be a gdm3 problem, but a gnome wayland session doesn't show it. The window border problem is the bigger issue: e seems to draw borders whether or not windows should have them, and there doesn't seem to be any way to remove them. I use enlightenment-git wayland (Arch/Arch Aur) every day, it works. What is your distro, is it updated? -- Maderios ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Wayland problems
On Sat, Jan 12, 2019 at 9:48 AM Carsten Haitzler wrote: it's been working a charm for me for months now... :) little things here and there have been fixed, but it's pretty much good. Ok, got it working :) I now have a build that will run under either Wayland or Xorg, based on which session i choose to log in. This is based on the efl and enlightenment from git, using the efl configuration parameters from that AUR archive (without any of the disabler ones set). However, now i still have my original two problems: an extra cursor image in the middle of the screen, and no control over the window borders. In fact, under the window menu, the "border" entry is missing. If i go into "locks", "do not allow border change" is checked. Unchecking it brings back the "border" entry, but top option, "select border style", is missing. The ghost cursor appears where the cursor was positioned on the login screen before hitting enter after typing my password. If i switch back to gdm's login screen, move the cursor around, then switch back, the ghost cursor is in the new position. I can get rid of it by switching to a vt that doesn't have this cursor and then back to e (wayland). This may be a gdm3 problem, but a gnome wayland session doesn't show it. The window border problem is the bigger issue: e seems to draw borders whether or not windows should have them, and there doesn't seem to be any way to remove them. Thanks, -Conrad. -- Shine like thunder Cry like rain ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Wayland problems
On Fri, 11 Jan 2019 17:23:58 -0500 Conrad Knight said: > On Fri, Jan 11, 2019 at 3:24 AM Carsten Haitzler wrote: > > that's the meson based build - you can just use it as-is and copy & > > paste... :) > > I was under the impression that meson building wasn't quite working > yet for efl. I just gave it a go, and it wants a more recent version > of meson, anyway... it's been working a charm for me for months now... :) little things here and there have been fixed, but it's pretty much good. > > you did want an explanation... :) > > Thanks for the info-dump, that's exactly what i was looking for! Would > it be safe to just enable "everything" in efl, or would there be > conflicts? there will be. read the hel output and readme which covers some options too. > And, related, i just checked "glxinfo" in a wayland session (Ubuntu > has a login option for gnome in either wayland or xorg) and noticed it > was running the "mesa project and sgi" version instead of the nvidia > one i have in xorg. Does that mean not hardware accelerated (or at > least, not by my video card)? i don't know - not enough details, BUT glxinfo would be going fix x. you'd have the xserver (xwayland) handling that and the xwayland server presents wayland surfaces to the wayland compositor without a root window being visible as a compatibility path for older x apps. it depends on what xwayland has done to enable acceleration or not. i have since moved on from all nvidia devices mostly due to the pretty poor state of nouveau and nvidia's reluctance to follow years of advice from the OSS community on what to do to support wayland (implement the gbm support that mesa has - they asked what to do, were told to do this, then a year or whatever later came back with something entirely different - eglstreams.). efl and enlightenment don't support eglstreams and we have no plans to do so. so no nvidia drivers for wayland for us - just nouveau, and they have been pretty poor in my experience with regular kernel lockups and slowdowns (system seems to hang the kernel in some timeout operations and userspace goes down to like 1/100th of normal speed whilst the screen is blank or hung on the last frame). > It looks like there are some more things for me to work out before i > give wayland another shot. > > On switching back, i seem to have messed something up... i've deleted > everything in /usr/local/ that got installed in the past few days, did > a "make clean", and "configure" with my usual options, "make", "make > install" for efl-1.21.1 and enlightenment-0.22.4 (released versions), > and now i can't login! I can start a bare X session, and run > enlightenment_start from an xterm, but this is hardly ideal. Trying to > start it from gdm directly just dumps me back at the login screen. Any > suggestions? I made sure to remove the > /usr/share/wayland-sessions/enlightenment.desktop file i had added, so > it's not trying to run a wayland session and failing (i think...?). > And "enlightenment_remote -desktop-show 2 1" now gives an error: I don't really know what gdm does. I haven't used gdm in maybe a decade or more. :) if enlightenment_start runs, then e runs. whatever is trying to launch e is somehow getting something wrong and getting logs and info from what it's doing is the key to finding out. > Error org.freedesktop.DBus.Error.UnknownMethod: Method "Show" with > signature "ii" on interface "org.enlightenment.wm.Desktop" doesn't > exist did you not load the msgbus module that extends e's dbus api with some more calls like this? :) > Thanks, > -Conrad. > > -- > Shine like thunder > Cry like rain > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Wayland problems
On Fri, Jan 11, 2019 at 3:24 AM Carsten Haitzler wrote: > that's the meson based build - you can just use it as-is and copy & paste... > :) I was under the impression that meson building wasn't quite working yet for efl. I just gave it a go, and it wants a more recent version of meson, anyway... > you did want an explanation... :) Thanks for the info-dump, that's exactly what i was looking for! Would it be safe to just enable "everything" in efl, or would there be conflicts? And, related, i just checked "glxinfo" in a wayland session (Ubuntu has a login option for gnome in either wayland or xorg) and noticed it was running the "mesa project and sgi" version instead of the nvidia one i have in xorg. Does that mean not hardware accelerated (or at least, not by my video card)? It looks like there are some more things for me to work out before i give wayland another shot. On switching back, i seem to have messed something up... i've deleted everything in /usr/local/ that got installed in the past few days, did a "make clean", and "configure" with my usual options, "make", "make install" for efl-1.21.1 and enlightenment-0.22.4 (released versions), and now i can't login! I can start a bare X session, and run enlightenment_start from an xterm, but this is hardly ideal. Trying to start it from gdm directly just dumps me back at the login screen. Any suggestions? I made sure to remove the /usr/share/wayland-sessions/enlightenment.desktop file i had added, so it's not trying to run a wayland session and failing (i think...?). And "enlightenment_remote -desktop-show 2 1" now gives an error: Error org.freedesktop.DBus.Error.UnknownMethod: Method "Show" with signature "ii" on interface "org.enlightenment.wm.Desktop" doesn't exist Thanks, -Conrad. -- Shine like thunder Cry like rain ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Wayland problems
On Thu, 10 Jan 2019 15:20:14 -0500 Conrad Knight said: > On Thu, Jan 10, 2019 at 1:39 PM Carsten Haitzler wrote: > > As usual - wayland stuff is kind of new and experimental so I'd advise using > > git master for that. > > as for how to compile - look at the aur git pkgs: > > Ok, i'll give it a shot :) Couple of quick questions: > > For EFL, are "--enable-egl" and "--enable-gl-drm" not needed, then? > What configure option does "-Dbuffer=true" correspond to? > Does "-Dopengl=es-egl" mean "--with-opengl=es"? Because i don't see > any other options besides "full" or "none". that's the meson based build - you can just use it as-is and copy & paste... :) > I have to admit, i'm a little lost on the differences and requirements > for opengl, gl-drm, egl, es-egl, etc. Is there by any chance a short > reference to all these terms? once upon a time there was opengl. it included glue to the display system called glx. then it needed to work on something other than x11, so the glx functions were replaced by wgl or agl functions on windows and mac (i never looked at or touched them but i know that they exist somewhere). then the embedded world appeared with gpus on small devices and the whole opengl api was a bit too fat. it was trimmed down to opengl-es. at the same time a unified egl api was added to a separate egl library this was now "cross platform" and could be used regardless of target display system. once upon a time linux had no opengl acceleration infrastructure at the kernel level. drm was born (direct rendering manager) as the kernel interface. it also came together with dri (direct rendering infrastructure) so often the naming was interchanged. there was now a libdrm library that acted as a front-end to opening /dev/dri/card0,1,2, etc. and doing ioctl()'s and read()ing/write()ing/mmap()ing it etc. this api also took on control of kms when it turned up (kernel mode switching) to set modes and atomically swap buffers. efl has 2 gl modes. opengl + glx, or opengl-es + egl. wayland required you use egl. while in theory you can do opengl + egl, we do not offer that as an option and we do stick to almost entirely using a subset of opengl that is common with opengl-es. these days we COULD drop opengl entirely, but many years ago desktop systems only offered opengl and embedded only offered opengl-es. today mesa offers both for all the drivers i know of and nvidia also offer both even on desktops. some embedded systems have gotten to offering opengl in addition to opengl-es. so in order to use gl efl has to switch to opengl-es mode as that then allows us to work with egl and support wayland. our drm based engines (2 of them) use libdrm to render directly to the "framebuffer" but with kms etc. drm is just software based where the cpu renders to buffers and we flip buffers. some drm implementations actually can only offer basic framebuffer management like this and no gpu support. this also then works if you have a fully accelerated opengl-es stack or not. the gl_drm is what it says on the lid - uses gl with drm to have gpu based acceleration. only opengl-es though. you did want an explanation... :) > Thanks, > -Conrad. > > -- > Shine like thunder > Cry like rain > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Wayland problems
On Thu, Jan 10, 2019 at 1:39 PM Carsten Haitzler wrote: > As usual - wayland stuff is kind of new and experimental so I'd advise using > git master for that. > as for how to compile - look at the aur git pkgs: Ok, i'll give it a shot :) Couple of quick questions: For EFL, are "--enable-egl" and "--enable-gl-drm" not needed, then? What configure option does "-Dbuffer=true" correspond to? Does "-Dopengl=es-egl" mean "--with-opengl=es"? Because i don't see any other options besides "full" or "none". I have to admit, i'm a little lost on the differences and requirements for opengl, gl-drm, egl, es-egl, etc. Is there by any chance a short reference to all these terms? Thanks, -Conrad. -- Shine like thunder Cry like rain ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Wayland problems
On Thu, 10 Jan 2019 12:48:26 -0500 Conrad Knight said: As usual - wayland stuff is kind of new and experimental so I'd advise using git master for that. as for how to compile - look at the aur git pkgs: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=efl-git https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=enlightenment-git :) That should get you up to date on the options. Indeed that wiki page is not up to date > I've followed the instructions on this page: > > https://www.enlightenment.org/about-wayland > > adding the necessary configure options. (Note: > --enable-wayland-clients and --enable-wayland-egl for enlightenment's > configure are not recognised. I used --enable-wayland instead.) > > I'm using efl 1.21.1 and enlightenment 0.22.4. > > Everything seems to work, except for these two problems: > 1) There's a big, fat arrow cursor in the center of the screen. I > would say it's the default X cursor, but this is wayland... It's > separate from the normal cursor, which functions as expected. It's a > static cursor image that appears on top of everything else. git :) > 2) Window decorations appear to be broken! I have a borderless > terminology window, and completely decoration-free conky windows open > on startup, and they all have borders and drop shadow. Programs (such > as Chrome) that manage their own decorations and positioning also have > an enlightenment border added, creating a double-border effect, and > their positioning over-ridden. try git. i use it very often on a range of ARM boards and all of this works. Out of the box. > Are there fixes or configuration settings to correct either of these? > > Another quick question -- that same web page mentions a wayland-only > option, but the link to those instructions says it's not safe for > everyday use. Is this still the case? Obviously, until the above > problems are fixed, i'm not about to compile enlightenment without X > support. I've never enabled wayland only. I want xwayland to work so there is x compatibility for apps/toolkits that cant do wayland yet. :) > Thanks, > -Conrad. > > -- > Shine like thunder > Cry like rain > > > ___ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users