I'm running GNOME on Angstrom Linux on a Beagleboard, and have an issue when the device boots, i'm running the 2013-06-20 image from http://beagleboard.org/latest-images.
Power on, and the screen will display the Beagleboard logo, and continues to boot up. The screen goes black, but instead of loading onto the desktop, the screens (I've tried a few just to make sure) report no output from the device. If i move the mouse/press a key on the keyboard however it wakes up and displays the desktop.
Has anyone else experienced this? Is there a way to prevent this 'sleep mode' (I doubt that's what it is, its just the best phrase I can think of describe this problem) from happening and just to boot up & display the desktop?
Cheers.
This seems to have fixed the issue I was having, firstly I'd suggest updating any outdated packages by opening a terminal and typing
opkg update
this should only take ~1 minute, aftewards type
opkg upgrade
This can take anywhere from ~10minutes to ~6 hours maybe even more, so be patient, just leave the device alone until it has finished.
then open the following file
nano /etc/X11/xorg.conf
and add the following
Section "ServerFlags"
Option "BlankTime" "0"
Option "StandbyTime" "0"
Option "SuspendTime" "0"
Option "OffTime" "0"
EndSection
Section "Monitor"
Option "DPMS"
Identifier "Builtin Default Monitor"
EndSection
This should also disable any screensavers etc... which was also ideal for my requirements.
Reboot your device, and it should be good to go.
Related
On modern Fedora Linux installations, pressing the computer's "power off" button does not actually shut it down, but rather hibernates it, which is very convenient.
However, this is only true if I run the default Gnome window manager. If I use a different window manager (my favorite is the old-school ctwm), this doesn't happen - the power-off button shuts down the system instead of hibernating.
My question is: How can I tell my system (I don't mind a little coding, and it doesn't need to be inside ctwm) to do something else - and not a shutdown - when the poweroff button is pressed. Without Gnome.
I did a little digging, and it appears that I have "upowerd" running. However, it is running just the same when ctwm and Gnome are the current window manager, so Gnome must somehow be telling upowerd not to power-off the computer and instead either do something else (like hibernate) or send Gnome that the event happened. But I couldn't find any documentation on how that's done, or how I can do something similar without Gnome.
Just installed pop_OS 20.10. My laptop is connected to a second monitor, I usually have both monitors display the same image.
Every time I boot it changes my display settings to "Join Displays" and then overlaps the two display (I don't know why overlapping the displays is even possible.
I change the display settings to something reasonable but they change back after a restart.
Is there any proper fix for this, or a hacky fix such as changing display settings in a shell script and adding the shell script to startup? (I couldn't find how to change settings through a shell script)
You will want to disable the HiDPI Daemon which is in the Settings -> Display.
REDDIT thread
I've got a bit of an interesting problem here. There are plenty of threads I've found where people are working to hide or get rid of a cursor on an embedded Qt GUI...but I'm trying to get a cursor to show up on an embedded Qt GUI.
I inherited a project that was 'finished' some time ago, and the person who did the most work on the project has moved on. Fast forward to today and there is a need to add a cursor to this functional touchscreen GUI. The system OS is Yocto Linux, and it is running a Qt 5.4 application on a framebuffer.
I've scoured the Qt code and there is nothing there that would hide a cursor. I've added in the appropriate QT_QPA_FB_HIDECURSOR=0 environment variable to my Qt startup script. I've experimented with adding a QCursor obejct to the GUI. Unfortunately none of these things are working. Using the QCusor I am sometimes able to get a cursor up on the screen, but isn't tied to the touch input (the cursor shows up at the position I programatically move it to, but it stays there when I interact with the GUI).
My touch input events are tied into Qt (via QT_QPA_GENERIC_PLUGINS=evdevtouch and QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS=/dev/input/event9:rotate=180), but for some reason that touch input cannot be tied to a cursor.
At this point I've spent a few days messing around with environment variables and startup script modifications, but nothing I've done has got the result I'm looking for.
Does anybody out there have some ideas on where to look for solutions to this problem?
Thanks!
Ian
So, now 3 months later I think my team and I just came up with a passable solution to this problem.
The path towards the solution started with the Qt Documentation on "Using libinput". The documentation boils down to a few important statements:
Parameters like the device node name can be set in the environment variables QT_QPA_EVDEV_MOUSE_PARAMETERS, QT_QPA_EVDEV_KEYBOARD_PARAMETERS and QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS
The mouse cursor shows up whenever QT_QPA_EGLFS_HIDECURSOR (for eglfs) or QT_QPA_FB_HIDECURSOR (for linuxfb) is not set and Qt's libudev-based device discovery reports that at least one mouse is available. When libudev support is not present, the mouse cursor always show up unless explicitly disabled via the environment variable.
The evdevtablet plugin provides basic support for Wacom and similar, pen-based tablets. It generates QTabletEvent events only. To enable it, pass QT_QPA_GENERIC_PLUGINS=evdevtablet in the environment or, alternatively, pass -plugin evdevtablet argument on the command-line. The plugin can take a device node parameter, for example QT_QPA_GENERIC_PLUGINS=evdevtablet:/dev/event1, in case the Qt's automatic device discovery (based either on libudev or a walkthrough of /dev/input/event*) is not functional or misbehaving.
So, in my system I have the device nodes: event0, event1, event2, event3, event4, event5, mice, and mouse0. Because I'm trying to get the mouse working, I made the assumption that I'd have to use the mouse0 node. This lead to me setting these environment variables:
QT_QPA_GENERIC_PLUGINS=evdevmouse
QT_QPA_EVDEV_MOUSE_PARAMETERS=/dev/input/mouse0
Much to my frustration these environment variables led to nothing. After some time my team and I figured out how to get debug output from Qt source on our system:
Modifying source code in the qtbase directory under our yocto build (roughly /yocto/poky/build/tmp/work/temp build directory/qtbase
Copying qtbase/plugins/generic/libqevdevmouseplugin.so to my hardware (roughly /usr/lib/qt5/plugins/generic)
Running Qt from the command line
We quickly discovered that the input events coming from mouse0 and mice were basically garbage data. On our system we did set up EVDEV in the kernel, so the mouse input was also tied to the device node event0. When we tried setting the Qt mouse parameter to event0 we started to see debug output that looked like real data.
QT_QPA_GENERIC_PLUGINS=evdevmouse
QT_QPA_EVDEV_MOUSE_PARAMETERS=/dev/input/event0
However, the problem of no-mouse-pointer still remained. After a while we looked back at the Qt Documentation, specifically at the 2nd paragraph listed above. As a last ditch attempt we tried adding in the QT_QPA_FB_HIDECURSOR environment variable...
QT_QPA_GENERIC_PLUGINS=evdevmouse
QT_QPA_EVDEV_MOUSE_PARAMETERS=/dev/input/event0
QT_QPA_FB_HIDECURSOR=0
And...voila! After countless hours of debugging and reading documentation, we finally got a mouse pointer.
I think the main crux of our issue was misinterpreting the Qt Documentation.
The mouse cursor shows up whenever ... QT_QPA_FB_HIDECURSOR (for linuxfb) is not set
By "not set", Qt means explicitly defined as FALSE...not simply "not set" at all.
This solution will work for us, but it does leave at least one thing to be desired. Along the way I stumbled across this thread answer on the Unix StackEx which points to the Kernel documentation of input/input.txt. In section "3.2.2 mousedev" you can see the line:
Each 'mouse' device is assigned to a single mouse or digitizer, except
the last one - 'mice'. This single character device is shared by all
mice and digitizers, and even if none are connected, the device is
present. This is useful for hotplugging USB mice, so that programs
can open the device even when no mice are present.
What this means for us is that while we can use event0 (which goes away when we unplug the mouse) for our mouse input event handling, we won't be able to support hot plugging without making some kernel/Qt-source modifications or figuring out how to get mice working as a Qt mouse input parameter.
So, the question of "why does event0 work and not mouse0/mice" still stands...but for now we've got a solution we can live with.
UPDATE: Now a little bit later we've figured out that udev was not working properly on our system. We added udev to the RDEPENDS in our package group for the Yocto build, and now we can set
QT_QPA_GENERIC_PLUGINS=evdevmouse
and we get a working mouse pointer with hotplug support.
I dont know if this applies to your problem (i dont use QT), but there is a
HAVE_TOUCHSCREEN=1 variable in the machconfig file. It is located normally in your BSP-layer in a recipes-bsp/formfactor/formfactor directory.
Setting this to 1 makes the cursor invisible.
Try setting it to 0
Im runing Solaris 10 - but im having problems with the keyboard.
Instead of - i get /, and instead of y i get z, etc. I tried changing every option in the menu "Keyboard Behaviour". I also tried changing kmdconfig from xorg to xsun, but then the graphics goes all wild and ugly - although the keyboard works fine then. Also cant change resolution in xsun mode.
By the way, im runing Solaris from Vmware, but i doubt this has anything to do with this.
Leave the graphic environment to the console:
dtconfig -d
dtconfig -reset
Select the correct keyboard layout you use:
kbd -s
Load it:
loadkeys
Check the keys are working properly. If okay, enable the graphical environment again:
dtconfig -e
If that still works, make that choice persistent after a reboot by updating your eeprom. eg:
eeprom kbd-type=Spanish
This should be migrated to superuser.com
It seems that you are expecting a german keyboard layout but are getting a US layout - at least the differences you are seeing are differences between those layouts. I don't know where to change that in openSolaris, but maybe it helps you find the correct place to look. Whatever desktop environment that you are using, it should have a tool to change the keyboard layout, probably somewhere with the other internationalization settings.
This is obviously a stupid question.
I am coding in Eclipse both on Mac and Linux, but I mixed up and used the Mac shortcut to window tabbing (Ctrl-Cmd-F6), but I was using the Linux on uni and screen went black. I've done this before, but this time I can't get back to my desktop. Ctrl-Alt F1-F6 gives me different terminals, F7 gives me a black screen and F8 a blinking underscore in the top left corner. Shouldn't my session have been somewhere in F1-F6 and is it lost?
Ctrl-Alt-F7 should work perhaps your X has crashed?
I just did what you did and F7 got it back for me, saying that before I remember X crashing and I had the same black screen
I had the same issue. I tried with hitting ctl+ alt + F1 together. And it worked
X is probably still running on F7, your display driver (or something else) is just misbehaving. You might be able to trick it into coming back on by going to F7 and blindly opening a terminal and playing with xset ($ xset dpms force on). Or you can ctrl-alt-backspace to kill X and GDM should restart it.
Try seeing if you can repeat the problem and then file a bug report (or let the lab admin know if it isn't your computer). It probably has something to do with your distro's kernel configuration/patching. I've had this happen before on Ubuntu but not any other distros (I've used many), which is why I am assuming it might be distro-specific issue. Probably the unintended consequences of some kernel patching.
The ctrl+alt+Fx (x=1..6) key combinations often allow you to have up to 6 concurrent terminal sessions on the console.
Usually one is setup to use X windows, and differs from distribution to distribution. Typically its on Ctrl+Alt+F7.
http://linux.about.com/od/linux101/l/blnewbie5_1.htm
Some distributions of Linux allow you to kill the X Windows session with Ctrl+Alt+Backspace at which point the operating system will attempt to restart it.
alt + F1
works for ubuntu 18.04.
In the future, you can go into a terminal and type:
init 3
To bring the system into text mode, and:
init 5
To return the system to X mode. The nice thing about doing it that way is that everything should be shut down and restarted cleanly.
For My case. I tried with hitting
ctl+ alt + F2
together. And it worked in Fedora
Try Ctrl-Alt-F9, and Ctrl-Alt-F10. :-)
Looks like X crashed. To check, you could log in on one of the terminals (on Ctrl+F1 etc.) and check that the "X" process is still running.
I've had the same happen to me recently, and found the SIGSEGV and backtrace later in /var/log/Xorg.0.log. Curse your graphics driver vendor (usually) and then reboot.
We're running gnome on Red Hat 5.
ps axu in one of the other terminals showed some of the processes still running. Probably something with the display drivers then. Did ctrl-alt-backspace and restarted it. Thanks for the help.
F8 solves the problem in Linux Mint 17.3 Rosa