An awesome app called Qingy - Part 2

Message

dayul · Post by **dayul** » Tue Jan 23, 2007 9:09 pm

Hi,

I have a problem with qingy. Everything works fine until i shutdown/reboot. When i do this, my machine shuts down, but i see neither the system shutdown messages, nor qingy telling me it is shutting down. Instead i see an ugly portion of my X desktop that covers the whole screen.
I have tried debug logging, but it didn't appear to bring up any error messages in the log file. I have also tried adding the -n qingy argument in inittab, but neither help.

Any suggestions would be much appreciated.

Thanks.

Split off from part 1 due to size. Part 1 is here
NeddySeagoon

s4t4n · Post by **s4t4n** » Wed Jan 24, 2007 11:33 am

dayul wrote:Hi,

I have a problem with qingy. Everything works fine until i shutdown/reboot. When i do this, my machine shuts down, but i see neither the system shutdown messages, nor qingy telling me it is shutting down. Instead i see an ugly portion of my X desktop that covers the whole screen.
I have tried debug logging, but it didn't appear to bring up any error messages in the log file. I have also tried adding the -n qingy argument in inittab, but neither help.

Any suggestions would be much appreciated.

Thanks.

Well, it appears you have some issue with the de-initialization of DirectFB... you have two options here:
1- you pass '-n' to qingy command line arguments
this way DirectFB would be de-initialized and system shutdown messages appear.
I guess this is the mode you are using and the one causing you problems.
2- you do not pass the '-n' atgument
this way DirectFB mode it NOT de-initialized and you see a message saying something
like 'machine is going down' until it either reboots or powers off

If not seeing system shutdown messages is not an issue for you, you can switch to option (2)...

dayul · Post by **dayul** » Wed Jan 24, 2007 11:40 am

Hi s4t4n, thank you for your comments.

Well, it appears you have some issue with the de-initialization of DirectFB... you have two options here:
1- you pass '-n' to qingy command line arguments
this way DirectFB would be de-initialized and system shutdown messages appear.
I guess this is the mode you are using and the one causing you problems.

Yes this is correct, when i do this i do not see the system shutdown messages, but a corrupted screen.

2- you do not pass the '-n' atgument
this way DirectFB mode it NOT de-initialized and you see a message saying something
like 'machine is going down' until it either reboots or powers off

Again this is a problem, instead of the message saying that the 'machine is going down' i see a corrupted screen. I have tried both with and without the '-n' option, but i see the same corrupted screen in both cases.

If not seeing system shutdown messages is not an issue for you, you can switch to option (2)...

I would rather see the system shutdown messages, however at the moment i am seeing neither system shutdown message, or 'machine is going down' (or similar) message. This is the problem i am seeing.

dayul · Post by **dayul** » Wed Jan 24, 2007 11:45 am

I should have added here that i only see the problem when shutting down/rebooting directly from X. If i first exit, and then use qingy to shutdown, it does it fine. So it seems to be the transition from X back to qingy that is the problem.

s4t4n · Post by **s4t4n** » Thu Jan 25, 2007 7:10 am

dayul wrote:I should have added here that i only see the problem when shutting down/rebooting directly from X. If i first exit, and then use qingy to shutdown, it does it fine. So it seems to be the transition from X back to qingy that is the problem.

This explain everything:
if you shutdown/reboot directly from X, it may happen that qingy respawns while X is still active (due to the shutdown process sending signals to everything), leading to qingy trying to initialize its GUI while X is still trying to shut itself down, thus to the screen corruption you just mentioned. There is nothing that qingy can do about that.

dayul · Post by **dayul** » Thu Jan 25, 2007 8:21 am

Ok, well thanks for letting me know. I wonder if there is some way that instead of calling /sbin/shutdown from X, i can effectively first log out of X, and then shutdown from qingy automatically using a script. Is that possible?

dmvianna · Post by **dmvianna** » Thu Jan 25, 2007 9:55 am

s4t4n wrote:You can try this: enable DEBUG logging in qingy and start an X session, in the logs should appear the arguments qingy is passing to xinit in order to start your session. Close your session. You could then (try to) start xinit in a shell, passing it the same arguments that are in the logs. If it fails, some message should appear stating what is wrong.

At first glance, it would appear that PAM is failing to set some environment variables at the first run, but gets it right later on...

Well, I can't find the arguments qingy is passing to X in /var/log/qingy.log:

Code: Select all

Jan 25 20:39:22, qingy-DirectFB on tty1, [DEBUG] You chose a screen saver timeout of 5 minutes.
Jan 25 20:39:22, qingy-DirectFB on tty1, [DEBUG] You chose a screen power management timeout of 30 minutes.
Jan 25 20:39:22, qingy-DirectFB on tty1, [DEBUG] added keybinding: 'win' will switch to left tty...
Jan 25 20:39:22, qingy-DirectFB on tty1, [DEBUG] added keybinding: 'menu' will switch to right tty...
Jan 25 20:39:22, qingy-DirectFB on tty1, [DEBUG] added keybinding: 'ALT-p' will poweroff machine...
Jan 25 20:39:22, qingy-DirectFB on tty1, [DEBUG] added keybinding: 'ALT-r' will reboot machine...
Jan 25 20:39:22, qingy-DirectFB on tty1, [DEBUG] added keybinding: 'ALT-s' will activate screen saver...
Jan 25 20:39:22, qingy-DirectFB on tty1, [DEBUG] added keybinding: 'ALT-z' will put machine to sleep...
Jan 25 20:39:22, qingy-DirectFB on tty1, [DEBUG] added keybinding: 'CTRL-ESC' will revert to text mode...
Jan 25 20:39:22, qingy-DirectFB on tty1, [DEBUG] The following logging facilities will be used: FILE 
Jan 25 20:39:22, qingy-DirectFB on tty1, [DEBUG] Session locking is NOT enabled.
Jan 25 20:39:22, qingy-DirectFB on tty1, [DEBUG] Theme cursor:
----> snip <-----
Jan 25 20:39:22, qingy-DirectFB on tty1, [DEBUG]   Cursor:
Jan 25 20:39:22, qingy-DirectFB on tty1, [DEBUG]     enable:    1
Jan 25 20:39:22, qingy-DirectFB on tty1, [DEBUG]     path:      Hand.png
Jan 25 20:39:22, qingy-DirectFB on tty1, [DEBUG]     x_off:     0
Jan 25 20:39:22, qingy-DirectFB on tty1, [DEBUG]     y_off:     0
Jan 25 20:39:22, qingy-DirectFB on tty1, [DEBUG] (*) DirectFB/Config: Parsing config file '/etc/directfbrc'.
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG]        ---------------------- DirectFB v0.9.25 ---------------------
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG]              (c) 2000-2002  convergence integrated media GmbH  
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG]              (c) 2002-2004  convergence GmbH                   
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG]         -----------------------------------------------------------
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG] (*) DirectFB/Core: Single Application Core. (2006-12-28 09:38) 
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG] (*) Direct/Memcpy: Using MMX optimized memcpy()
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG] (*) Direct/Thread: Running 'PS/2 Input' (INPUT, 8865)...
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG]  (!!!)  *** UNIMPLEMENTED [fusion_reactor_set_lock] *** [reactor.c:853]
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG] (*) DirectFB/Input: IMPS/2 Mouse 1.0 (Convergence GmbH)
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG] (*) Direct/Thread: Running 'Keyboard Input' (INPUT, 8866)...
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG] (*) DirectFB/Input: Keyboard 0.9 (convergence integrated media GmbH)
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG] (*) DirectFB/Genefx: MMX detected and enabled
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG] (!) Direct/Modules: Unable to dlopen `/usr/lib/directfb-0.9.25/gfxdrivers/libdirectfb_unichrome.so'!
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG]     --> /usr/lib/directfb-0.9.25/gfxdrivers/libdirectfb_unichrome.so: undefined symbol: cos
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG] (*) DirectFB/Graphics: MMX Software Rasterizer 0.6 (convergence integrated media GmbH)
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG] (*) DirectFB/Core/WM: Default 0.2 (Convergence GmbH)
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG] (*) Direct/Interface: Loaded 'FT2' implementation of 'IDirectFBFont'.
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG] (*) Direct/Interface: Loaded 'JPEG' implementation of 'IDirectFBImageProvider'.
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG] (*) Direct/Interface: Loaded 'PNG' implementation of 'IDirectFBImageProvider'.
Jan 25 20:39:23, qingy-DirectFB on tty1, [DEBUG] Found new screen (1 so far): FBDev Primary Screen, has power management support
Jan 25 20:39:33, qingy-DirectFB on tty1, [DEBUG] Starting GUI shutdown...
Jan 25 20:39:33, qingy-DirectFB on tty1, [DEBUG] GUI shutdown complete
Jan 25 20:39:33, qingy on tty1, [DEBUG] GUI exited

But I'm wondering if it couldn't be a kernel bug instead, as I'm using 2.6.19-gentoo-r4, and I been getting weird stuff from time to time when booting. Also, I got some strange errors in the failure-related X logs:

Code: Select all

(WW) xf86CloseConsole: KDSETMODE failed: Input/output error
(WW) xf86CloseConsole: VT_GETMODE failed: Input/output error
(WW) xf86CloseConsole: VT_ACTIVATE failed: Input/output error

Or in another try, after weird irreproducible DRI-related errors:

Code: Select all

(EE) Error loading keymap /var/tmp/server-2.xkm

Now, I really don't think it should be hard disk failure. But from your experience, where do you think the problem might be, so I start a new thread or look for help under the right title?

s4t4n · Post by **s4t4n** » Thu Jan 25, 2007 1:09 pm

dmvianna wrote:Well, I can't find the arguments qingy is passing to X in /var/log/qingy.log, but I'm wondering if it couldn't be a kernel bug instead, as I'm using 2.6.19-gentoo-r4, and I been getting weird stuff from time to time when booting. Also, I got some strange errors in the failure-related X logs:
Code: Select all
(WW) xf86CloseConsole: KDSETMODE failed: Input/output error
(WW) xf86CloseConsole: VT_GETMODE failed: Input/output error
(WW) xf86CloseConsole: VT_ACTIVATE failed: Input/output error
Or in another try, after weird irreproducible DRI-related errors:
Code: Select all
(EE) Error loading keymap /var/tmp/server-2.xkm
Now, I really don't think it should be hard disk failure. But from your experience, where do you think the problem might be, so I start a new thread or look for help under the right title?

Well, you will get the args in qingy logs only if you use qingy 0.9.5 (which is still masked). I cannot say about your other failures... if you think you have a failing HDD, you can install smartd and see what it says...

dmvianna · Post by **dmvianna** » Fri Jan 26, 2007 3:30 am

s4t4n wrote:Well, you will get the args in qingy logs only if you use qingy 0.9.5 (which is still masked). I cannot say about your other failures... if you think you have a failing HDD, you can install smartd and see what it says...

I've installed qingy 0.9.5, it worked on reboot, then I disabled AIGLX, and X is starting much faster and more smoothly. I'm not sure which one was more critical for the fix, but I am really thinking it was an ati-drivers issue. Anyway, it works, I'll stop complaining.

s4t4n · Post by **s4t4n** » Fri Jan 26, 2007 9:53 am

dmvianna wrote:I've installed qingy 0.9.5, it worked on reboot, then I disabled AIGLX, and X is starting much faster and more smoothly. I'm not sure which one was more critical for the fix, but I am really thinking it was an ati-drivers issue. Anyway, it works, I'll stop complaining.

Both, maybe

Be wary of ati-drivers, on my machine they do not like suspend-to-disk at all, and they tend to explode if I want to start more than one X server at the same time...

s4t4n · Post by **s4t4n** » Fri Jan 26, 2007 9:56 am

s4t4n wrote:Both, maybe
Be wary of ati-drivers, on my machine they do not like suspend-to-disk at all, and they tend to explode if I want to start more than one X server at the same time...

Also, if you have an ati maybe you are using the ati kernel framebuffer driver, too, instead of the vesa one. If this is the case, keep in mind that this driver has a serious bug that DirectFB tends to trigger. The fix is a one liner, have a look here...

dmvianna · Post by **dmvianna** » Sun Jan 28, 2007 8:15 am

s4t4n wrote:Also, if you have an ati maybe you are using the ati kernel framebuffer driver, too, instead of the vesa one.

No, I use vesafb. Is there any reason why I should go for radeonfb? Is it better in any way?

s4t4n · Post by **s4t4n** » Mon Jan 29, 2007 7:45 am

dmvianna wrote:
s4t4n wrote:Also, if you have an ati maybe you are using the ati kernel framebuffer driver, too, instead of the vesa one.
No, I use vesafb. Is there any reason why I should go for radeonfb? Is it better in any way?

It is better only if your display has some strange resolution (like 1280x800) and you want to use it...

Tlaloc · Post by **Tlaloc** » Sat Feb 03, 2007 9:34 am

I still have problems with any qingy version newer than 0.7.4.
0.9.4 gave me some corruption with X.
0.9.5 seems to work fine but after logging out from an X session and then starting again a session it takes quite a while (5-10 sec) for it to come up. It doesn't seem that X tries to start more than once, I just have a black screen. That is the oly hint I have (dmesg):

Code: Select all

ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
[fglrx] total      GART = 130023424
[fglrx] free       GART = 114032640
[fglrx] max single GART = 114032640
[fglrx] total      LFB  = 134086656
[fglrx] free       LFB  = 117657600
[fglrx] max single LFB  = 117657600
[fglrx] total      Inv  = 0
[fglrx] free       Inv  = 0
[fglrx] max single Inv  = 0
[fglrx] total      TIM  = 0
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
[fglrx] PCIe has already been initialized. Reinitializing ...     <--This seems suspicious
[fglrx] total      GART = 130023424
[fglrx] free       GART = 114032640
[fglrx] max single GART = 114032640
[fglrx] total      LFB  = 134086656
[fglrx] free       LFB  = 117657600
[fglrx] max single LFB  = 117657600
[fglrx] total      Inv  = 0
[fglrx] free       Inv  = 0
[fglrx] max single Inv  = 0
[fglrx] total      TIM  = 0
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
[fglrx] PCIe has already been initialized. Reinitializing ...
[fglrx] total      GART = 130023424
[fglrx] free       GART = 114032640
[fglrx] max single GART = 114032640
[fglrx] total      LFB  = 134086656
[fglrx] free       LFB  = 117657600
[fglrx] max single LFB  = 117657600
[fglrx] total      Inv  = 0
[fglrx] free       Inv  = 0
[fglrx] max single Inv  = 0
[fglrx] total      TIM  = 0

Shouldn't be there a log somewhere with 0.9.5?

EDIT: Downgraded to 0.7.4 and all works well. The dmesg entries are the same, so it seems that this is as it should be and not a sign of problems. With 0.9.5 it just seems that X starts a little bit faster.

Bye, Val.

Ehnvis · Post by **Ehnvis** » Tue Mar 06, 2007 7:39 am

I got a minor problem (or atleast I hope so). A few days ago i finally came back to gentoo (after running both WinXP and Ubuntu) on my laptop
and got most of the stuff up and running. Decided to install qingy as login manager and it took me a few hours to figure out why I only got the
text login (had to add USE="directfb" to the emerge qingy line) but this isnt the problem as I got the graphical to work, it's much more annoying.

When I logon and qingy starts X I have 2 black squares, anywhere on the screen 9x5 pixel in size, with a blinking cursor in em. And they stay there
for the duration of my session. If I fallback to an agetty they are gone? Anyone have an idea on what the hell is going on?

Running DirectFB 0.9.25, qingy 0.9.5 and xorg 7.1 (modular). Laptop is the one in my sig, ATI IGP 340M videocard.

avx · Post by **avx** » Tue Mar 06, 2007 11:30 am

When I logon and qingy starts X I have 2 black squares, anywhere on the screen 9x5 pixel in size, with a blinking cursor in em. And they stay there
for the duration of my session. If I fallback to an agetty they are gone? Anyone have an idea on what the hell is going on?

Same problem here. I can get around this by switching to a vt not running quingy (strg+alt+f6 in my case) and then switching back to the running X-session - quite annoying but not as anoying as keeping the blinky-thing, which btw also stays there while playing a fullscreen opengl-game(q3a f.e.).

I've got this for nearly two months now...for the matter, my versions are the same as from the guy above, but using an GF6800 with latest prop.drivers.

tia,
ph

s4t4n · Post by **s4t4n** » Wed Mar 14, 2007 2:09 pm

ph030 wrote:Same problem here. I can get around this by switching to a vt not running quingy (strg+alt+f6 in my case) and then switching back to the running X-session - quite annoying but not as anoying as keeping the blinky-thing, which btw also stays there while playing a fullscreen opengl-game(q3a f.e.).

I've got this for nearly two months now...for the matter, my versions are the same as from the guy above, but using an GF6800 with latest prop.drivers.

tia,
ph

Well, I'm hit by this, too, but only once after I restart my machine, and the workaround works nicely. My guess is that, since qingy starts X in the same tty it (qingy) is invoked, there are two interactive processes living in that tty, X and the shell that started it (startx, on the other hand, starts the X server in the first unused tty). This is correct behavior from qingy, because, since it is possible to start more than one X server at the same time, it would be confusing to see them pop up on random ttys instead of the ones you would expect them. Yet, it also triggers this quirk (but only on some machines), which may be annoying for some people. I could add an option to qingy settings file that would tell it to fire up X server in an unused tty. What do you think about this?

Ehnvis · Post by **Ehnvis** » Wed Mar 14, 2007 5:48 pm

That is a great idea and I would love to see that feature in qingy.

avx · Post by **avx** » Wed Mar 14, 2007 9:55 pm

That is a great idea and I would love to see that feature in qingy.

++ :)

BTW, please don't forget my request considering the font-sizes and besides, I would love to have "Text:Console" only titled "Console" or even better to give it a name myself.

cheers,
ph

PS: Is there something like a dropdown-field for users on the roadmap?

ibnpaul · Post by **ibnpaul** » Tue Mar 20, 2007 7:09 pm

Since I gathered that this is kind of the unofficial (or maybe official ) Qingy support thread, I have a question. Does one need to install DirectFB if they have framebuffer support compiled into the kernel and are using their graphics card's fb driver? I ask because while qingy runs, I don' get the nice graphical login screen, just text mode like getty (the session picking works though). I thought that this might be the reason, but I am not sure. Can anyone shed some light on this? Thanks!

s4t4n · Post by **s4t4n** » Wed May 09, 2007 9:56 am

ibnpaul wrote:Since I gathered that this is kind of the unofficial (or maybe official ) Qingy support thread, I have a question. Does one need to install DirectFB if they have framebuffer support compiled into the kernel and are using their graphics card's fb driver? I ask because while qingy runs, I don' get the nice graphical login screen, just text mode like getty (the session picking works though). I thought that this might be the reason, but I am not sure. Can anyone shed some light on this? Thanks!

Yes, qingy relies on DirectFB for its GUI.

thor_n · Post by **thor_n** » Tue Oct 02, 2007 6:16 am

Hi,

I'm using latest (unstable) sys-apps/qingy-0.9.6-r1
and still see that blinking cursor at the top left corner when I log into X.

I tried your workaround:

Code: Select all

x_server_tty = unused_tty

but it did not help.

I found yesterday, that when I hit enter on session type (wmaker, console and such) instead of in password input box I do not get this annoying black square with blinking cursor.

Hope this helps to eliminate this little bug.

Except for this little thing I'd love to customize following:
- timeout (going down in 5 seconds)
- all text messages (system going down, ...)
- font size, color, position of all messages.

Thanks,

s4t4n · Post by **s4t4n** » Wed Oct 10, 2007 9:18 am

thor_n wrote:I found yesterday, that when I hit enter on session type (wmaker, console and such) instead of in password input box I do not get this annoying black square with blinking cursor.

Hope this helps to eliminate this little bug.

This is *really* strange! I'll investigate...

thor_n wrote:Except for this little thing I'd love to customize following:
- timeout (going down in 5 seconds)
- all text messages (system going down, ...)
- font size, color, position of all messages.

I'll add these to the TODO list...

lord2800 · Post by **lord2800** » Tue Oct 23, 2007 3:26 am

I just got qingy installed and configured and working as I like it, and I ran into a problem: I can't get synergy working with it. Is there any way to work around that? I have my keyboard/mouse connected to a different system, and I can't change it over unfortunately (multimedia keyboard and the extra keys don't translate well over synergy).

s4t4n · Post by **s4t4n** » Thu Nov 15, 2007 1:37 pm

lord2800 wrote:I just got qingy installed and configured and working as I like it, and I ran into a problem: I can't get synergy working with it. Is there any way to work around that? I have my keyboard/mouse connected to a different system, and I can't change it over unfortunately (multimedia keyboard and the extra keys don't translate well over synergy).

Well, this is the wrong place to ask this question: since qingy relies on DirectFB for graphics, input devices, etc (at least if you are not running it in text mode only), it is the DirectFB folks that should be asked about synergy support. Anyway, what is your problem exactly? Input does not work at all, or stops working when you switch to another machine and back again?