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
--not-when-fullscreen... again #23
Comments
What DE/WM are you using? This has occured to me in xmonad due of a lack of EWMH hints. To debug this, please run the following command and click a fullscreen window.
EDIT: Oh, and xidlehook version would be great! |
WM is leftwm. Will update with other info when I get home again, but I did check that |
|
I assume the window is the selected one? See #19 |
yes, it is the focused window. |
I'm afraid I don't have much time to debug this at the moment, especially since I can't reproduce it :( If you'd like, you can spray some Line 416 in 152d057
|
I'm going to be out of touch for the next week or so but when I get back I'll give it a look and see if I can figure it out. Thanks. |
Just wondering if you could help me understand this bit of code from x11api.rs:
I don't see where |
Of course! Both A good sanity check would be to add |
Amazingly debugged :)! When you ran |
Not sure, but just did it again and got
The sleep was so I could use the mouse to focuse FF before xprop ran. The output was the same when chromium is fullscreen and focused. That was with XFCE. With leftwm the output is less verbose (but again identical for FF and chromium):
|
What's the output if you replace if *data.0.offset(i) == atom { with if dbg!(*data.0.offset(i)) == atom { ? |
Only thing I can think of is wrapping those |
What output you would expect? |
So xprop admits that yes, there are a bunch of values for the property In case I misunderstood, and you're asking what return value I expect from the two functions I asked you to wrap, 0 is the standard in C to specify success. Non-zero usually means failure, and a negative value almost certainly means failure. But what type of failure is interesting! |
In leftwm, xprop for non-fullscreen window is empty for that property:
Also I may have inadvertently introduced some confusion. I was trying to figure out what the XGetWindowProperty call was doing and had it print the return of that which is where that extra zero in the screenshots comes from. Wrapping XGetWindowProperty in dbg returns 0, but XGetInputFocus returns 1 no matter what window is focused. This is true for both leftwm and XFCE. |
I ignored that actually, but that's useful. Seems like |
|
Interesting, and highly useful. Unless I'm mistaken, that 1 means |
Nope, same on my system. When googling for how to handle errors I stumbled across a rant about Xlib, and rust-xcb which is a safe API. Guess that module is due for a rewrite... Be right back!! |
Update: The xcb change is out, available at 7faf3e0. Xcb is amazing and rust-xcb is even more so. I'm hopeful that, if anything, this will work for you. But no promises. At least we might get better error handling by default, which could lead us a step on debugging. So please do try this commit :D |
Will have to spend some more time looking into it, but for now it does not seem to recognize a fullscreen window whether it is the focused window or not. |
Not even for things that previously worked, like chromium (I think you mentioned?) |
Hello, I am having the same problem using awesome v4.3 with xidlehook 0.7.0 and trying to watch movies in fullscreen in either YouTube or Netflix. This is my script:
That's the output of Tell me if you need more information. |
Thanks! Would you be so kind as to send me the output of xidlehook? Turns out I left a What happens if you get the latest git version and run cargo run --bin xidlehook -- --timer normal 5 "echo hi" "" --not-when-fullscreen and then try experimenting with and without fullscreen? |
Hmm, really weird. It gives me
|
Oh. It only checks for fullscreen status on active windows - that's a feature... or lack thereof, I guess. Feel free to drop a comment on #19 if you want that expanded. |
Sorry, but I'm at a loss here. Maybe I misunderstood something? I would be happy if it (correctly) checked for fullscreen status on active windows such as Netflix or YouTube, which is not the case. |
My bad, it is indeed supposed to check fullscreen status of other active windows. I must have misread the following:
I thought you meant when the window that's fullscreen is focused. Did you mean the only output that occurs is when you run EDIT: Your two values for |
I also get unwanted screen locks when using FF to watch netflix with xidlehook 0.7.1 (using xprop says |
What do the debug logs say? Run the latest xidlehook with |
For this test I started xidlehook 0.8.1, switched to a workspace with a fullscreen firefox and waited for the timer to trigger.
|
Damn interesting, so I guess the question is reduced to: why would |
Of course, xprop uses the exact same call I've used previously... Idk, have you tried if version 0.7.1 works? It's using the X call directly, no XCB middleman. I mean it's unlikely, but I don't know how to proceed here, the docs on that function are pretty bad. |
Yes, it has the same problem. I originally had the problem with 0.7.1 and only updated to provide up to date debugging info for this ticket. |
Update: I experience this after switching to AwesomeWM! I can finally reproduce & attempt to fix it |
From my side, the error happens because the active window is actually different from the fullscreen window. To fix this, xidlehook would need to check all windows. |
Alright, does the latest master work as you'd expect? I made it check all windows instead |
I'm having a similar issue, I think. If Firefox is fullscreen it will still trigger the screenlock. If audio is running it will still trigger screen dimming but not lock.
Originally posted by @stevensonmt in #5 (comment)
The text was updated successfully, but these errors were encountered: