Sean Meighan
Software => Bugs in xLights/Nutcracker => Topic started by: olorin92 on September 23, 2018, 04:53:11 PM
-
Hi all,
When using the .AppImage file in Arch Linux, I cannot for the life of me get my house preview showing anywhere. The picture of my house is set as the background, it's set to fill, and it's 100 brightness, but the right panel shows nothing.
It's as if the area that normally shows the picture hasn't actually loaded, because I only see the grey of the window underneath (not the usual black when an image hasn't been loaded).
I've attached a screenshot to show what I see.
I'm assuming that I'm missing a package or there's something weird with my graphics setup, but can't quite figure it out.
I'm using the 2018.33 version of XLights, but have also tried on the 2018.18 version and got the same issue.
-
Can you please upload your /tmp/xLights_l4cpp.log logfile for me?
Also - try moving ~/.xLights aside (such as rename it to ~/.xLights-old ) as that contains all your settings and so will reset things to default in case there is some odd config issue. If that doesn't help you can move the file back to restore your settings
-
Can you please upload your /tmp/xLights_l4cpp.log logfile for me?
Also - try moving ~/.xLights aside (such as rename it to ~/.xLights-old ) as that contains all your settings and so will reset things to default in case there is some odd config issue. If that doesn't help you can move the file back to restore your settings
Hi debenham,
Thanks for the speedy reply! I did think of that, but unfortunately had no luck when moving/removing that folder. I've attached that file as requested! Having a look at it, I can't see any warning or error messages for the last time I ran xLights, so nothing is jumping out to me at least!
-
Nothing jumps out to me either.
I'll try and reproduce - what version of arch linux are you running, what desktop environment are you using and what GPU are you using?
-
Nothing jumps out to me either.
I'll try and reproduce - what version of arch linux are you running, what desktop environment are you using and what GPU are you using?
So that's where it gets a bit iffy! I'm on the latest Arch Linux, latest Gnome, but the graphics is a bit of a weird setup. I'm running it on an XPS 15, which has a GTX 1050, but I've disabled that with bbswitch and should be using the onboard graphics exclusively.
-
Ahh - graphics cards can mess all sorts of things up due to how wxwidgets/gtk2/GL interact :(
Do other GL applications work okay (such as glxgears as a test)?
In xlights under the settings menu you can try forcing the version of OpenGL used - maybe try playing with that to see if it helps.
-
Ahh - graphics cards can mess all sorts of things up due to how wxwidgets/gtk2/GL interact :(
Do other GL applications work okay (such as glxgears as a test)?
In xlights under the settings menu you can try forcing the version of OpenGL used - maybe try playing with that to see if it helps.
Yep glxgears works fine, and I did try playing around with the OpenGL settings too - no joy there either!
-
getting arch linux running with GL under virtualbox is not working for me :( (some issues with vboxvideo xorg module not being available anymore for arch)
So I haven't been able to re-produce - but I do know that there are some others using xLights on arch so it 'should' work.
My best guess is that the onboard graphics and the nvidia graphics are getting confused with each other.
Can you try it with the GTX active?
-
Still no luck!
Not sure what it is about my environment, but there's definitely something XLights doesn't like :(
-
It's very strange... the GL canvases are being created. However, they aren't being asked to actually "paint". Thus, the GL context isn't being created.
I'm having a similar issue on OSX Mojave, but a simple click on the panel causes a repaint so it more or less fixes itself with a mouse click.
-
It's very strange... the GL canvases are being created. However, they aren't being asked to actually "paint". Thus, the GL context isn't being created.
I'm having a similar issue on OSX Mojave, but a simple click on the panel causes a repaint so it more or less fixes itself with a mouse click.
Odd...I mean for now it's not a huge issue as I can just my windows VM, but I'd much rather be using the Linux box! I also don't seem to be able to add timing marks in a basic animation sequence - whether or not that's related I'm not sure.
-
Ok so running the AppImage with optirun seems to allow the house preview to show correctly. This forces the application to use the discrete graphics card, so I'm not sure why the intel graphics seem to be having such an issue with running xLights, but Nvidia graphics is doing fine.
Interesting!
-
OK I might have spoken too soon...I don't seem to be able to use any keyboard shortcut (ctrl c and v for copy and paste for instance), and as a result I can't manually add timing marks - hitting T does nothing when running a sequence.
Any ideas?
-
I don't know if it'll solve all your problems but try closing Xlights and then delete your key binding file from your show folder then reopen Xlights.
-
Hitting T never does anything you gotta hit t. :)
-
Hitting T never does anything you gotta hit t. :)
Problem solved! ;)
But in all seriousness, I hadn't thought of that! Alas my shortcuts don't seem to be working still - some seem to work (like the function keys) but copy/paste and timing marks still seem to be doing nothing.
Perhaps I should build from the repo and see if I get any joy running directly from there...
EDIT: Timing marks seem to be working properly now! Now to figure out why it refuses to copy/paste...
-
I don't know if it'll solve all your problems but try closing Xlights and then delete your key binding file from your show folder then reopen Xlights.
Did you try this advice?
-
I don't know if it'll solve all your problems but try closing Xlights and then delete your key binding file from your show folder then reopen Xlights.
Did you try this advice?
Sorry just realised I didn't explicitly state that - yes I did remove the bindings xml file. So my timings seem to be working properly now, just not copy/paste. I'll keep looking and see if there's any obvious reason why that is though
-
Copy and paste do not refer to the keybindings.
Sent from my iPhone using Tapatalk
-
Copy and paste do not refer to the keybindings.
Sent from my iPhone using Tapatalk
Ok so potentially something related to the graphical issues I'm getting, given that seems to be specific to my setup. I think I’ll do a build and see if I get any joy, if I do then there must be something weird with the way the AppImage is packaged and my environment.
If not, then just my environment!
-
Ok finally got the depencies right on my machine to do the build successfully. After running the built binary, it seems to display the graphics fine, without having to use the dedicated graphics card.
Copy/Paste still isn't working, but I'm happy at least that the graphics seem to work properly now.
I do suspect this means there is something in the AppImage build process that my machine doesn't like. Finding out what that is might be the next step I suppose!
-
Linux sure seems like a troublesome OS and when I tried it I found it a pain that every program you wanted to use you had to figure out if it was compatible with the 8000 versions of Linux. I just don't get love for that OS.
-
Linux sure seems like a troublesome OS and when I tried it I found it a pain that every program you wanted to use you had to figure out if it was compatible with the 8000 versions of Linux. I just don't get love for that OS.
Yep I can understand that view, some of us are masochists ;) but to be fair some things I’ve just found so much easier on a Linux box than windows - dev related setups especially
-
OK so I think I've found the issue. The switch statement that is used to process the normal key bindings for copy and paste seems to depend on the preprocessor symbol __WXMSW__ being present - looking this up here: https://docs.wxwidgets.org/3.0/page_cppconst.html (https://docs.wxwidgets.org/3.0/page_cppconst.html) seems to suggest this will only be present when using Windows controls in the GUI - which I'm assuming won't be the case when using Linux?
I'm happy to fiddle with this and alter the code to handle my scenario (once I figure out what preprocessor symbol is actually present), then create a pull request if that helps?
-
I don't see where you mentioned exactly what you are trying to copy/paste. I can tell you those wxWidgets docs probably have nothing to do with how our code works because we are capturing the keystrokes and executing copy/paste inside our code its not handled by wxWidgets.
-
OK so I think I've found the issue. The switch statement that is used to process the normal key bindings for copy and paste seems to depend on the preprocessor symbol __WXMSW__ being present - looking this up here: https://docs.wxwidgets.org/3.0/page_cppconst.html (https://docs.wxwidgets.org/3.0/page_cppconst.html) seems to suggest this will only be present when using Windows controls in the GUI - which I'm assuming won't be the case when using Linux?
I'm happy to fiddle with this and alter the code to handle my scenario (once I figure out what preprocessor symbol is actually present), then create a pull request if that helps?
Umm.. where are you looking? The MainSequencer::OnChar method that handles the copy/paste keys doesn't have a single #ifdef in it.
-
Sorry - I'm doing the copy and paste in the layout view, not the sequencer. I'm attempting to copy and paste a model
-
I don't see where you mentioned exactly what you are trying to copy/paste. I can tell you those wxWidgets docs probably have nothing to do with how our code works because we are capturing the keystrokes and executing copy/paste inside our code its not handled by wxWidgets.
The keystrokes are being handled yes, but part of that handling (including the copy paste functionality) is wrapped in that ifdef - and the preprocessor symbol it's look for (at least for me) isn't present. The cases of the switch statement that handle the copy paste don't even get hit because the symbol is missing. If I remove that ifdef for instance, it works properly (not saying this is the solution, but that it's definitely causing it to not work).
I was trying to figure out why that ifdef was there as, like you said, the functionality in the switch statement doesn't seem like it would be broken without it because it's being done outside of wxWidgets
-
If would be best if you list filenames and line numbers when you start trying to describe a section of code. When you say something like "the cases of the switch statement" I have no idea what code you are staring at.
Normally a copy/paste is done by clicking on the model's picture and not it's name in the list. Which way are you trying to do it? I'm just finding it hard to believe you are the first Linux user to ever try to copy a model.
-
I was trying to figure out why that ifdef was there as, like you said, the functionality in the switch statement doesn't seem like it would be broken without it because it's being done outside of wxWidgets
It likely should be an "#if !defined(__WXOSX__)"
On the Mac, the Copy/Cute/Paste is handled by those menu items on the main menu. The accelerators kick in and call the appropriate methods. Thus, without the ifdef, we ended up getting double pastes.
-
If would be best if you list filenames and line numbers when you start trying to describe a section of code. When you say something like "the cases of the switch statement" I have no idea what code you are staring at.
Normally a copy/paste is done by clicking on the model's picture and not it's name in the list. Which way are you trying to do it? I'm just finding it hard to believe you are the first Linux user to ever try to copy a model.
Sorry in my eagerness I did leave some detail out. File in question is here: https://github.com/smeighan/xLights/blob/master/xLights/LayoutPanel.cpp (https://github.com/smeighan/xLights/blob/master/xLights/LayoutPanel.cpp) and the ifdef I'm mentioning is on line 2838.
To copy, I'm simply clicking the model in the layout then ctrl+c and ctrl+v to paste
Certainly not suggesting this is more widespread, but possibly something to do with my machine not generating that preprocessor symbol during compilation, while other's machines are
-
I was trying to figure out why that ifdef was there as, like you said, the functionality in the switch statement doesn't seem like it would be broken without it because it's being done outside of wxWidgets
It likely should be an "#if !defined(__WXOSX__)"
On the Mac, the Copy/Cute/Paste is handled by those menu items on the main menu. The accelerators kick in and call the appropriate methods. Thus, without the ifdef, we ended up getting double pastes.
Ahh ok that makes sense then! At least then it handles the case you mentioned without excluding everything else not using the Windows GUI controls
-
Ok thanks. I'm not at home so I wasn't able to browse the code very easily. I can look online on GitHub but its not as easy as what I can do at home. You had me thinking you were looking at a #ifdef inside wxWidgets. Sounds like Dan's suggestion is the way to go.
-
I was trying to figure out why that ifdef was there as, like you said, the functionality in the switch statement doesn't seem like it would be broken without it because it's being done outside of wxWidgets
It likely should be an "#if !defined(__WXOSX__)"
On the Mac, the Copy/Cute/Paste is handled by those menu items on the main menu. The accelerators kick in and call the appropriate methods. Thus, without the ifdef, we ended up getting double pastes.
Just confirming this does indeed allow copy and paste to function properly on my machine (and I'm hoping it still allows OSX to work without doing a double copy, but I'll need to rely on someone with a Mac to test that).
Given this was your solution, did you want to do the commit for the change dkulp? Or do you want me to do a PR?
-
BTW - regarding the original gui bug - the appimage includes a number of libraries and so as part of its running it sets up library paths etc. The problem with dual-vendor GPU systems (ie onboard graphics + nvidia GPU) is that there is a bunch of trickery done to get the right GL stuff loaded which is likely getting messed up/confused by appimage.