-
Notifications
You must be signed in to change notification settings - Fork 30
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
fullscreen compilation patch - odd behavior relating to fakefullscreen client functionality #9
Comments
Nice! That's some writeup, much appreciated. I had not noticed the borders disappearing in fake fullscreen mode - I'll look into it and get back to you. |
Been playing with this some more, issues 1 and 2 appear to be completely solved. Issue 3 is still giving me a hard time, although in and of itself is very minor. It might be easier to visualize what is going on if you apply the noborder patch, because I think its related to the client losing focus in this situation: In
This is the noborder patch with the check for
The client should now be reverted back to tiled + fakefullscreen, and there should now be a border drawn around the client, but only on the left and top edges. Strange right? I only bring this one up because following the same steps causes the same result I outlined in my previous post regarding issue 3:
Calling As always, I welcome any insights you may have. edit - I think it has to be something to do with the new variables in |
Not related to the issues you are noting here, but you may want to drop that trailing
I was not able to replicate this. Could it be that you still have some of the other changes we tried, like the moving of the I'll have a look to see if I can replicate the focus issue. |
OK, so yes I can replicate the focus issue. The focus change has to do with an enter notify signal being received for the client underneath the cursor when you go from fullscreen to fake fullscreen. This is something that is handled by the X server. I was able to work around this by explicitly passing True to the XSync call within the resize function, which, according to https://tronche.com/gui/x/xlib/event-handling/XSync.html causes the X server to disregard all events in the queue. So essentially we are cancelling that enter notify signal before it is sent. I am not entirely sure what other implications this might have.
|
…ng from fullscreen to fake fullscreen, ref. #9
Excellent find with the XSync fix! I didn't have much time to dig deep into the X server side of things last night, but the issue felt very familiar to a conversation we had a while back regarding focusing on hidden clients when you came up with the
Whoops, not sure how that snuck in there, that was a mistake. I'll edit my original post in case someone is doing some google-fu and happens upon it.
Everything in This most recent commit appears to solve everything from what I can tell, including the border issue you weren't able to replicate. Which seems to confirm my suspicion that the border issue I described earlier was tied to the (apparently) enternotify event regarding fakefullscreen clients. Interestingly, with this fix, rapidly enabling fake fullscreen on single clients no longer appear to flicker on my system either. I'll have to play around with it some more to see if I can force something to break, or if I can come up with some other weird consistency issues but as far as I can tell I think this is pretty much solved! |
I figured there might be some obscure issues if the client window goes into fullscreen (like F11 in your browser), but it worked fine in all my test cases. |
OK, what do you think of this?
This fixes a super minor visual discrepancy when calling The problem with this approach means that since it is excluding floating windows from being lowered, the XSync fix will not apply to them either... Without this type of change, making a client fakefullscreen while the client was already fullscreen(actual) would cause it retain it's "raised" state. Just can't seem to figure out a good way to properly exclude floating windows from being lowered while still retaining the Edit I should point out that this can probably only be observed while running a compositor with a shadow offset -- its very minor and doesn't affect anything functional. I'm 99% sure what I described above is the reason it behaves this way though. |
You are probably going to laugh, but @@ -1296,7 +1296,10 @@ resizeclient(Client *c, int x, int y, int w, int h)
wc.border_width = c->bw;
XConfigureWindow(dpy, c->win, CWX|CWY|CWWidth|CWHeight|CWBorderWidth, &wc);
configure(c);
- XSync(dpy, False);
+ if (c->fakefullscreen == 1) {
+ if (!c->isfloating)
+ XLowerWindow(dpy, c->win);
+ XSync(dpy, True);
+ } else
+ XSync(dpy, False);
}
Aha! Busted, so you are using an external bar :D If I am understanding it correctly, you actually want the bar to be displayed on top of clients? Do you actually have a case where tiled windows are overlapping the bar? I am just trying to understand the exact use-case for lowering the window here. Note that this is in the Before you made the edit you had this as well:
This I can replicate. I suspect that this is an implication of the noborder patch. When you press F11 in the browser the browser sends a notification to the window manager and we end up in the The code as-is triggers this: if (c->fakefullscreen == 1)
resizeclient(c, c->x, c->y, c->w, c->h);
else
setfullscreen(c, (cme->data.l[0] == 1 /* _NET_WM_STATE_ADD */
|| (cme->data.l[0] == 2 /* _NET_WM_STATE_TOGGLE */
&& !c->isfullscreen
))); I suspect the issue here is that we are just keeping the same position and height and width as we do currently, but there is no border and the noborder patch adds the border size to the new dimension. Quite possibly one could just ignore the signal if the client is in fake fullscreen, but I suspect that it is necessary to call setfullscreen in both cases. I notice that if you hit F11 in a fake fullscreen firefox window the client never properly exits fullscreen. I'll have a play around. |
I removed the changes in |
edit: structure of post Ah yes, I removed that bit regarding the noborder since I figured it wasn't related to this patch specifically -- turns out it sort of was :D I can confirm that is solved as well. Removing the changes in
Here is the order of events which triggers this as I understand them: 1: client receives fullscreen signal
Since the window is still "raised", it appears as if its floating above the bar even though it is tiled. As you can see, it is so minor and has no effect on anything besides appearances but I suspect it can be solved with the strategic placement of Perhaps this is best handled by an external script via the IPC patch though, like we discussed earlier? Otherwise, if this works as-is and the only thing I need to sacrifice is the centered floating master layout then so be it, I can live with that.
It seems to behave fine actually, with the exception of calling Can you think of a better way to check for this? I've tried playing around in I'll let you know if I find a solution. EDIT x2 Turns out I found a situation by accident where this actually does have a real effect. Try this:
Sorry to keep throwing you curve balls here, but I discovered this while trying to isolate even more weirdness I noticed relating to EDITx3 OK I am almost positive now that there is some cross talk happening between fullscreen, fakefullscreen, and floating states. Turns out I'm not insane after all. In this order:
I can replicate this 100% of the time. This will (hopefully) be my final edit on this post. Sorry for the lengthy write up, but this is almost certainly the issue. I think its probably related to the recorded states for fakefullscreen, which iirc you put in there to allow for swapping between fake/actual fullscreen modes regardless of the order they were triggered in. Hope this helps! |
Just to clarify something as you are repeating it many times, XRaiseWindow is not a state that is enabled or disabled. There is no "the client is in a raise state" vs "not in a raised state". This analogy is pretty good:
You do not want to ever call The case with the floating window is a valid one. It happens because, as you say, the The only sensible way to address this would be to call Is there an easy way to do that? Actually there is - we can call Now you may ask why you can't replicate this when just toggling fullscreen on and off? This has to do with that the |
@vide0hanz could you try out the latest changes in Only the I am not particularly happy with the overall solution as coding-wise it feels very hacky, but it will have to do for now. |
Just an update in case other people are reading up on this - I did a complete overhaul of all the setfullscreen logic (now available at the existing diff) which appears to have solved all of the issues outlined in this ticket. Right now I am just doing another round of regression testing before closing this one off. |
Can confirm the overhaul is solid based on my testing. Ive been trying to break it and I can't, all of the issues I mentioned previously are resolved from what I can tell. Will leave open until @bakkeby says otherwise. |
Confirming latest commit successfully resolves the obscure bug we discussed. For anyone that may be following this:
Before the most recent commit, the browser in question (firefox, in this example) would be in a simultaneous floating + fakefullscreen state. This has been resolved based on my testing. |
There were some not quite ideal situations when moving a fullscreen window between monitors that I found. Issue 1: Tiled window
Outcome
Solution
Issue 2: Floating window
Outcome:
Solution
Updated the patch. |
I can't say that I have spotted any fullscreen woes for well over a month, so I think it is time to close this. |
Hey again, sorry to keep spamming your github page. Figured this is better than reaching out on reddit. There a couple minor issues that are easily reproduced when using the fake fullscreen client functionality of the fullscreen compilation patch. Tested with a bare dwm (latest commit).
From what I can gather, most of these issues can be prevented by enabling actual fullscreen at any point before going into fakefullscreen mode (with the exception if 2.1 outlined below).
1 : When toggling fakefullscreen on any client on and then off, it removes the border of that client. However, if you go into actual fullscreen mode at any point before going into fakefullscreen mode, the client behaves as expected. Fake/actual fullscreen can now be toggled in any order and the borders remain.
Steps to reproduce:
2 : On floating clients, entering fakefullscreen works the first time, but exiting fakefullscreen removes the border in addition to placing it back in its tiled position. While the client is floating, going into actual fullscreen mode at any point before fakefullscreen prevents this as well.
Steps to reproduce:
2.1 : In an attempt to isolate issue 2, I discovered another odd scenario relating to floating clients:
Steps to reproduce:
3 : This last one is probably related to
unfocus()
. If you focus on a client and toggle actual fullscreen first, and then exit out of it by toggling fake fullscreen, the client loses focus in favor of the client where the mouse cursor is. In this scenario, the borders are fine, and the client goes into fakefullscreen - it just loses focus in favor of the mouse position. If the client is made fullscreen while already in fakefullscreen, toggling fakefullscreen off exits both of the fullscreen modes, which I'd say is the expected behavior.Steps to reproduce:
To summarize:
Fakefullscreen introduces some unexpected behavior when it is the first action called on any selected client. Nearly all of these issues can be prevented by calling actualfullscreen on the client at any point before fakefullscreen. The only instance where this is not the case is outlined in issue 2.1. Issue 3 remains mostly unaffected by this as well, as it has to do with the order the fullscreen modes are initialized.
Just wanted to bring this to your attention. I'm not sure where to look to even attempt to fix this myself, but I'm guessing
clientmessage()
,configurenotify()
, andunfocus()
. Any clue why fakefullscreen behaves this way? How is it so interlocked between the order in which fakefullscreen and actual fullscreen is called, in addition to the client state (tiled vs floating)?Hopefully this post is detailed enough to give you something to work with. I'm happy to test out anything you'd like me to change in my build of dwm and report back, and I'll of course share anything else I discover.
The text was updated successfully, but these errors were encountered: