-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wayland support #1390
Comments
I'm not a display server expert but as far as I know opengl "just" needs an egl context to draw think to a wayland surface, so basically it's just a matter of changing a couple of replacing a couple of glxCreate... fonction with their egl counterpart in COpenglDriver.cpp (and potentially CIrrDeviceLinux.cpp) if we want to use irrlicht (everything on screen is drawn by opengl, there is no X toolkit involved) That's why I would be more in favor of sdl2, it handles all the egl/glx logic which would allow us not to care if the underlying server is Xorg, wayland, dwm or Quartz, and have a common subset of input events. The issue is that stk still requires irrlicht to load the model and I'm worried that an "independent" sdl2 and irrlicht may conflict with each other. |
The big plus of SDL2 is that it's maintained and used by Valve, they use it for their source powered game. |
Currently X11 is used for:
As I see, you can already make irrlicht to use SDL by |
It's a fair point that I think SDL2 would be a great move to add next. It can abstract off the X11 stuff we are using which not only makes stk a little more compatible with other operating systems and fixes many issues I get with non-sdl games doing odd stuff with my display modes. SDL2 is bundled with every distro I can name and I would believe that most have it installed anyway. Things like tabbing out of fullscreen windows is also a nice thing to have for the very little effort that SDL2 requires. edit: and I might give a SDL2 port a try at some point, wasn't too hard to convert OGRE projects to SDL2. |
I just would like to ask, which plans we have about irrlicht engine in future?
I'm asking because I could do some experiments with wayland after 0.8.2 release. But I don't know if this would be useful at all (switch to SDL2 will make it certainly not useful). @Half-Shot SDL2 is still missing in Debian stable ;) It already is in wheezy-backports, but even in backports sdl_image and sdl_mixer modules are still missing. |
I'm not sure about Wayland. However even now it's considered that we forked irrlicht. After all the difficulties and the investment in this new engine we deserve We can't say without laying that we are using irrlicht. The changes are It's also more clear for Linux packager. As far as I know we aren't planning to update irrlicht. Instead we will I made an article on the wiki showing what the engine can do and also It's also very clear that it's not a stand alone engine and it can be used Btw off topic but deve are you the author of a soccer arena in the addons ? Sam
|
When we will replace irrlicht, then we could use SDL2 for managing window and input events. And trying to support wayland in our own way would be useless. Yes, I'm the author of soccer arena. I was trying to make something a bit more interesting for this rather boring game-type. But it's not finished. You can use it for something if you want ;) Edit: |
We still rely on irrlicht to load our texture and mesh at the moment, and for our animations. We're still far from replacing irrlicht. |
I opened a branch ("wayland") that adds an irrlicht driver for wayland. However I used Fedora 21 as a development/test platform (because gnome-shell as a wayland compositor is available out of the box as a gdm session, although not enabled by default) and thus it's likely harder to get it to build on others platforms. However there is no window decoration at the moment, and it only supports base protocol (I don't know where to get the xdg-shell protocol include file used by gnome wayland client) so fullscreen/windows title/... is not supported for instance. And I'm not sure gamepad works (although it looks like the joystick support doesnt rely on X11 for linux device). |
I would like to chime in just to say that the game works quite well via XWayland. I've been testing it on openSUSE Tumbleweed with GNOME 3.15 on Wayland but the game fails to capture the full screen (it's stuck in windowed mode) and won't detect all the proper screen resolutions. As far as performance goes, on XWayland, the game didn't lose any FPS at all and I experience absolutely no lags. If you guys are in need of someone to help test things, I would be glad to step in. I have a steering wheel and a DualShock 3 controller as well as wired and wireless mice and keyboards. I'll get to testing the input immediately. |
Did you check STK 0.8.1 or current git/beta version? They are using different methods to switch to fullscreen. Vlj already made some work on support Wayland. I will probably look at this after upcoming STK release. |
0.8.2 beta seems to be doing worse actually. It (naturally) doesn't start at all in a Wayland session and requires XWayland. When running under XWayland, attempting to change the resolution or switch to fullscreen mode crashes it. As for input, the DualShock 3 controller, the wireless and wired keyboards and mice, and the steering wheel are all properly detected and are as usable as they were on X11. Wayland log: /usr/games/supertuxkart [warn ] [IrrDriver Temp Logger]: Level 3: Could not open display, set DISPLAY variable [warn ] [IrrDriver Temp Logger]: Level 3: Error: Need running XServer to start Irrlicht Engine. [warn ] [IrrDriver Temp Logger]: Level 3: Could not open display, set DISPLAY variable [warn ] [IrrDriver Temp Logger]: Level 3: Error: Need running XServer to start Irrlicht Engine. [warn ] [IrrDriver Temp Logger]: Level 3: Could not open display, set DISPLAY variable [warn ] [IrrDriver Temp Logger]: Level 3: Error: Need running XServer to start Irrlicht Engine. [warn ] [IrrDriver Temp Logger]: Level 3: Could not open display, set DISPLAY variable [fatal ] irr_driver: Couldn't initialise irrlicht device. Quitting. User@linux:~> /usr/games/supertuxkart [warn ] [IrrDriver Temp Logger]: Level 3: Could not open display, set DISPLAY variable [warn ] [IrrDriver Temp Logger]: Level 3: Error: Need running XServer to start Irrlicht Engine. [warn ] [IrrDriver Temp Logger]: Level 3: Could not open display, set DISPLAY variable [warn ] [IrrDriver Temp Logger]: Level 3: Error: Need running XServer to start Irrlicht Engine. [warn ] [IrrDriver Temp Logger]: Level 3: Could not open display, set DISPLAY variable [warn ] [IrrDriver Temp Logger]: Level 3: Error: Need running XServer to start Irrlicht Engine. [warn ] [IrrDriver Temp Logger]: Level 3: Could not open display, set DISPLAY variable [fatal ] irr_driver: Couldn't initialise irrlicht device. Quitting. XWayland log: RGB profile [info ] GUIEngine: scale: 0.512000 |
Okay, it's also crashing on X11 when I attempt to change the screen resolution. It seems like a general problem and not just an XWayland issue. |
As I understend, there are two separated issues
First case may be caused by problems with access to xserver
Nobody test it on wayland, so this may happen... The second crash (on xorg session) certainly shouldn't happen. If you are able to compile current STK version yourself, could you create separated ticket and paste there backtrace from debugger? |
What is the current status of this? |
The wayland branch generally works fine, at least under Gnome. Last time that I was looking at this, there was a problem with window decorations. I mean, I wasn't able to find a way to make it drawn automatically. But SDL2 application had no decorations too, so maybe people from wayland assume that every application will draw window decorations personally :P Or it wasn't finished yet. There are also some missing functions such as minimize/maximize window, set title, resizeable etc... In EGL we should add fallback for legacy pipeline. I don't remember if there is joysticks support or not. |
A major problem with using EGL is that it's very buggy on X11. (See the "Removal of GLX/EGL selection" part.) Personally I see SDL2 as more future-proof than plain EGL and less duplicated work. But I'm only a novice at C++ and probably couldn't yet code this myself, so take my opinion with a grain of salt. |
EGL on X11 is not that bad, at least with mesa drivers. I'm using it with OpenGL ES renderer and I didn't have any issues so far. Anyway we don't have any plans to use it on X11 by default. It's needed only for Wayland and for GLES renderer. And actually it's just few lines of code for creating OpenGL context, which is already implemented. |
@deveee 2016 was the near future and still no one is using Wayland / Mir. |
I updated the wayland branch, so that now it can create/destroy EGL context using the same code as Android device. One thing that should be done and that is not directly related to wayland code is CSD (client-side decorations). It would be nice to have a possibility to close or minimize window using buttons... We may also need to update glew because version 2.0 has support for EGL. Or is GLEW really needed on linux? It should be useful mostly on windows, where we have to load all OpenGL functions dynamically. |
actually fedora use system glew anyway, maybe we patch it too? Just add an if unix and apple in front of it |
It also looks that we don't need patched glew anymore. It looks that it has been fixed in version 2.0: So I would be glad if we can update it. Maybe after STK 0.9.3 release? And indeed we can use system glew with restriction >= 2.0. |
A basic Wayland support is already done. You can enable it by using: Then you can choose the device by setting environment variable: What is currently missing:
And btw. GLEW upgrade is not needed for Wayland support. The |
A nice addition to the wayland device would be touch input support, so that it may be possible to play without a keyboard, in the same way as on android. So if someone has a laptop with multitouch screen and wants to test it, I can write some code. |
Regarding to the previous comment:
I think that most work is done and it should be already usable. So that I think that this ticket can be closed. One thing that is still missing is window decorations. I use server-side decorations on KDE, but other compositors currently don't allow to do it. Well it's possible to attach a subsurface and draw it yourself, but I think that it's just stupid. And I think that it's not our bug, but their design issue that affects multiple applications and will be fixed sooner or later. |
hello everyone! i made an irrlicht 1.9 GLES port for Wayland Sailfish. If you want, you can try use that for your game. I will try do it by my self later, i have no time now. https://github.com/savegame/sailfish-irrlicht sorry for my english =) @deveee, sorry, i not read this thread, irrlicht already has wayland support? i something miss? i was start make port of irrlicht to wayland on september of 2017, I didn't find wayland support for irrlicht. |
Irrlicht itself doesn't have wayland support, but we have wayland support in STK. It's mostly in CIrrDeviceWayland.cpp and CContextEGL files. And if you want to use your irrlicht with STK, it may be not trivial. It's probably easier to use your CIrrDeviceSailfish with our irrlicht. What is more interesting for me is that you implemented touch events. Do you have a possibility to test it? I'm asking, because we can already control a kart with touch device on android. And in theory it's possible to use it on wayland with touch screen. |
I not have much time =) but later i will try build your project in Sailfish SDK with my implementation ... just tell me how you connect irrlicht to your project? in what folder is situated sources of irrlicht, or it link as lib? |
@deveee Is the touch input code written? I have such laptop, could help :) |
If I didn't miss anything, this should be enough: And then I can check in runtime if touch device is available. |
The touch UI during the race works well after applying #3693 :) However, menus don't react to any touches - I have to use mouse on them. |
Thanks a lot for testing. Now GUI should work too. And I will add something like isTouchDeviceAvailable(). |
It started reacting, but something's wrong: when I touch firmly a button for the first time, it becomes hovered instead of clicked. I have to tap it twice. Also, when I touch lightly (quickly), sometimes the previously hovered button gets activated (clicked) instead of the one I touch now. |
Fixed in #3694 :) |
Actually on android I just set cursor position, but now I think that your way is better - when cursor position was changed, we should get "move" event. |
Now it should detect that your laptop has touch device, so you can make final test :) |
The touch screen is included on the list of the input devices and touching through the menu works, but the in-race touch interface doesn't appear now and there's nothing in the options menu to enable it :( |
You can click on a touch device and there should be "enable device"
checkbox.
|
Aaah, not sure how I missed that... Well, seems to be working! :) |
I got the interface showing, does not work though. I can't interact with it |
In near future (perhaps 1-2 years) main linux distributions (Ubuntu and Fedora) probably will use Wayland/Mir by default instead of X11. With Gnome 3.12 you can alredy run experimental Wayland session. Gnome 3.14 which will be released in autumn should have probably stable Wayland support. Even Nvidia works on support Wayland in their drivers.
I don't know if irrlicht developers have plans for support Wayland and Mir. I'm also not sure if we should wait for them or try to implement it. We have now a bit modified irrlicht version... Will we synchronise it with upstream irrlicht in future at all?
If currently a lot of work is done in pure OpenGL, maybe switch to SDL2 would be good idea? It already supports Wayland, Mir, Android and others. It seems to be better in handling window, keyboard input etc. than Irrlicht.
The text was updated successfully, but these errors were encountered: