cwm 6.2: Windows losing focus while cycling (ALT-TAB)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

cwm 6.2: Windows losing focus while cycling (ALT-TAB)

Ruben Miller
>Synopsis:      <cwm 6.2: Windows losing focus while cycling (ALT-TAB)>
>Category:      <Xwindow>
>Environment:
        System      : OpenBSD 6.2
        Details     : OpenBSD 6.2 (GENERIC.MP) #0: Thu Oct 12 19:53:18 CEST
2017
                         [hidden email]:
/usr/src/sys/arch/amd64/compile/GENERIC.MP

        Architecture: OpenBSD.amd64
        Machine     : amd64
>Description:
        <When cycling through windows in cwm sometimes the active client
misses the input focus. The bug is only present when we start the cycle in
a client with the WM_TAKE_FOCUS property.
I start to observe this after this commit:

https://marc.info/?l=openbsd-tech&m=149182817427598&w=2

Digging into the problem it's seems that raising two windows in every cycle
instead of one it's fast enough that triggers a race in the focus policy.
When the window manager raise a window that has WM_TAKE_FOCUS sends a
message with that atom to the client, which allows the application to
handle the input focus.
When cwm immediately raise another client there is a possibility for the
first one to claim the input focus after the new one becomes active. >
>How-To-Repeat:
        <Open a bunch of (10 o more) application without WM_TAKE_FOCUS
(like xterm or rxvt), and then open one with WM_TAKE_FOCUS, like emacs
(preferable, since is slow) or firefox.
Focusing in the last one (so it's became the previous window), cycle
(ALT-TAB) through the clients observing if they properly receive focus
while are active.
No need for releasing ALT. In my case, it's just takes a few ALT-TAB for
observing the condition>
>Fix:
        <The simplest way I find to solve the thing is not send
WM_TAKE_FOCUS when a client is set active and we are cycling, but force a
proper activation when ALT is released.


--- client.c.orig       Thu Oct 26 10:17:08 2017
+++ client.c    Thu Oct 26 10:19:20 2017
@@ -214,7 +214,7 @@
                XSetInputFocus(X_Dpy, cc->win,
                    RevertToPointerRoot, CurrentTime);
        }
-       if (cc->flags & CLIENT_WM_TAKE_FOCUS)
+       if (!sc->cycling && (cc->flags & CLIENT_WM_TAKE_FOCUS))
                client_msg(cc, cwmh[WM_TAKE_FOCUS], Last_Event_Time);

        if ((oldcc = client_current()) != NULL) {
@@ -722,9 +722,8 @@
        sc->cycling = 0;

        if ((cc = client_current()) != NULL) {
-               client_mtf(cc);
                cc->flags &= ~CLIENT_HIGHLIGHT;
-               client_draw_border(cc);
+               client_setactive(cc);
                XUngrabKeyboard(X_Dpy, CurrentTime);
        }
 }>

dmesg:
OpenBSD 6.2 (GENERIC.MP) #0: Thu Oct 12 19:53:18 CEST 2017
    [hidden email]:/usr/src/sys/arch/amd64/compile/
GENERIC.MP
real mem = 3060002816 (2918MB)
avail mem = 2960306176 (2823MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xea740 (49 entries)
bios0: vendor INSYDE version "1.40" date 06/03/2010
bios0: TOSHIBA Satellite L645
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP ASF! HPET APIC MCFG SLIC BOOT ASPT WDAT SSDT
acpi0: wakeup devices P0P2(S4) PEGP(S4) P0P1(S0) EHC1(S3) USB1(S3) USB2(S3)
USB3(S3) USB4(S3) EHC2(S3) USB5(S3) USB6(S3) USB7(S3) HDEF(S3) PXSX(S4)
RP01(S0) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i3 CPU M 350 @ 2.27GHz, 2261.42 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 2261416680 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 132MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i3 CPU M 350 @ 2.27GHz, 2261.00 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i3 CPU M 350 @ 2.27GHz, 2261.00 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 5 (application processor)
cpu3: Intel(R) Core(TM) i3 CPU M 350 @ 2.27GHz, 2261.00 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 2, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec00000, version 20, 24 pins
, remapped to apid 2
acpimcfg0 at acpi0 addr 0xe0000000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P2)
acpiprt2 at acpi0: bus 4 (P0P1)
acpiprt3 at acpi0: bus 1 (RP01)
acpiprt4 at acpi0: bus -1 (RP02)
acpiprt5 at acpi0: bus -1 (RP03)
acpiprt6 at acpi0: bus -1 (RP04)
acpiprt7 at acpi0: bus 2 (RP05)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG3)
acpiprt11 at acpi0: bus -1 (PEG5)
acpiec0 at acpi0
acpicpu0 at acpi0: C3(350@245 mwait.3@0x20), C1(1000@3 mwait.1), PSS
acpicpu1 at acpi0: C3(350@245 mwait.3@0x20), C1(1000@3 mwait.1), PSS
acpicpu2 at acpi0: C3(350@245 mwait.3@0x20), C1(1000@3 mwait.1), PSS
acpicpu3 at acpi0: C3(350@245 mwait.3@0x20), C1(1000@3 mwait.1), PSS
"PNP0C32" at acpi0 not configured
"SYN103F" at acpi0 not configured
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT1 not present
"QCI0701" at acpi0 not configured
"TOS1900" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: LID_
acpidock0 at acpi0: DOCK not docked (0)
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
cpu0: Enhanced SpeedStep 2261 MHz: speeds: 2266, 2133, 1999, 1866, 1733,
1599, 1466, 1333, 1199, 1066, 933 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core Host" rev 0x02
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x02
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xc0000000, size 0x10000000
inteldrm0: msi
inteldrm0: 1366x768, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 3400 MEI" rev 0x06 at pci0 dev 22 function 0 not configured
ehci0 at pci0 dev 26 function 0 "Intel 3400 USB" rev 0x05: apic 2 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev
2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 3400 HD Audio" rev 0x05: msi
azalia0: codecs: Conexant/0x5069, Intel/0x2804, using Conexant/0x5069
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 3400 PCIE" rev 0x05: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 4 "Intel 3400 PCIE" rev 0x05: msi
pci2 at ppb1 bus 2
"Realtek 8192SE" rev 0x10 at pci2 dev 0 function 0 not configured
ppb2 at pci0 dev 28 function 5 "Intel 3400 PCIE" rev 0x05: msi
pci3 at ppb2 bus 3
alc0 at pci3 dev 0 function 0 "Attansic Technology L1D" rev 0xc0: msi,
address c8:0a:a9:ce:5c:22
atphy0 at alc0 phy 0: F1 10/100/1000 PHY, rev. 15
ehci1 at pci0 dev 29 function 0 "Intel 3400 USB" rev 0x05: apic 2 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev
2.00/1.00 addr 1
ppb3 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xa5
pci4 at ppb3 bus 4
pcib0 at pci0 dev 31 function 0 "Intel HM55 LPC" rev 0x05
ahci0 at pci0 dev 31 function 2 "Intel 3400 AHCI" rev 0x05: msi, AHCI 1.3
ahci0: port 0: 3.0Gb/s
ahci0: port 1: 1.5Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: <ATA, TOSHIBA MK5065GS, GJ00> SCSI3 0/direct
fixed naa.500003928930a9a1
sd0: 476940MB, 512 bytes/sector, 976773168 sectors
cd0 at scsibus1 targ 1 lun 0: <TEAC, DV-W28S-VT, M.8C> ATAPI 5/cdrom
removable
ichiic0 at pci0 dev 31 function 3 "Intel 3400 SMBus" rev 0x05: apic 2 int 19
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 2GB DDR3 SDRAM PC3-8500 SO-DIMM
spdmem1 at iic0 addr 0x52: 1GB DDR3 SDRAM PC3-8500 SO-DIMM
itherm0 at pci0 dev 31 function 6 "Intel 3400 Thermal" rev 0x05
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pms0: Synaptics touchpad, firmware 7.2, 0x1c0b1 0xa40000
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
pci5 at mainbus0 bus 255
pchb1 at pci5 dev 0 function 0 "Intel QuickPath" rev 0x02
pchb2 at pci5 dev 0 function 1 "Intel QuickPath" rev 0x02
pchb3 at pci5 dev 2 function 0 "Intel QPI Link" rev 0x02
pchb4 at pci5 dev 2 function 1 "Intel QPI Physical" rev 0x02
pchb5 at pci5 dev 2 function 2 "Intel Reserved" rev 0x02
pchb6 at pci5 dev 2 function 3 "Intel Reserved" rev 0x02
vmm0 at mainbus0: VMX/EPT
uhub2 at uhub0 port 1 configuration 1 interface 0 "Intel Rate Matching Hub"
rev 2.00/0.00 addr 2
run0 at uhub2 port 2 configuration 1 interface 0 "Ralink 802.11 n WLAN" rev
2.00/1.01 addr 3
run0: MAC/BBP RT3071 (rev 0x0213), RF RT3022 (MIMO 2T2R), address
00:24:a5:aa:c8:2a
uhub3 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching Hub"
rev 2.00/0.00 addr 2
uvideo0 at uhub3 port 1 configuration 1 interface 0 "Sonix Technology Co.,
Ltd. CNF9055" rev 2.00/26.13 addr 3
video0 at uvideo0
umass0 at uhub3 port 4 configuration 1 interface 0 "Generic USB2.0-CRW" rev
2.00/58.89 addr 4
umass0: using SCSI over Bulk-Only
scsibus2 at umass0: 2 targets, initiator 0
sd1 at scsibus2 targ 1 lun 0: <Generic-, Multi-Card, 1.00> SCSI0 0/direct
removable serial.0bda0158114173400000
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
scsibus4 at softraid0: 256 targets
root on sd0a (4d6a1a4880fc65e3.a) swap on sd0b dump on sd0b

usbdevs:
Controller /dev/usb0:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000),
Intel(0x8086), rev 1.00
 port 1 addr 2: high speed, self powered, config 1, Rate Matching
Hub(0x0020), Intel(0x8087), rev 0.00
  port 1 powered
  port 2 addr 3: high speed, power 450 mA, config 1, 802.11 n WLAN(0x016f),
Ralink(0x0411), rev 1.01, iSerialNumber 1.0
  port 3 powered
  port 4 powered
  port 5 powered
  port 6 powered
 port 2 powered
 port 3 powered
Controller /dev/usb1:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000),
Intel(0x8086), rev 1.00
 port 1 addr 2: high speed, self powered, config 1, Rate Matching
Hub(0x0020), Intel(0x8087), rev 0.00
  port 1 addr 3: high speed, power 500 mA, config 1, CNF9055(0xb1d6), Sonix
Technology Co., Ltd.(0x04f2), rev 26.13
  port 2 powered
  port 3 powered
  port 4 addr 4: high speed, power 500 mA, config 1, USB2.0-CRW(0x0158),
Generic(0x0bda), rev 58.89, iSerialNumber 20071114173400000
  port 5 powered
  port 6 powered
  port 7 powered
  port 8 powered
 port 2 powered
 port 3 powered



--
Ruben Miller
Reply | Threaded
Open this post in threaded view
|

Re: cwm 6.2: Windows losing focus while cycling (ALT-TAB)

Walter Alejandro Iglesias-3
In article <[hidden email]> Ruben Miller <[hidden email]> wrote:
> >How-To-Repeat:
>         <Open a bunch of (10 o more) application without WM_TAKE_FOCUS
> (like xterm or rxvt), and then open one with WM_TAKE_FOCUS, like emacs
> (preferable, since is slow) or firefox.
> Focusing in the last one (so it's became the previous window), cycle
> (ALT-TAB) through the clients observing if they properly receive focus
> while are active.
> No need for releasing ALT. In my case, it's just takes a few ALT-TAB for
> observing the condition>

Perhaps I don't understand what you mean.  I opened 15 xterms and
seamonkey and cycled through windows up and down, slow and fast.
I didn't experience any problem.

I don't have emacs installed to try it.  Are you sure it is the
WM_TAKE_FOCUS the problem and not some emacs setting trying to steal
the focus what confuses cwm?


Reply | Threaded
Open this post in threaded view
|

Re: cwm 6.2: Windows losing focus while cycling (ALT-TAB)

Ruben Miller
In reply to this post by Ruben Miller
In article <[hidden email]> alter Alejandro Iglesias <
[hidden email]> wrote:

>Perhaps I don't understand what you mean.  I opened 15 xterms and
>seamonkey and cycled through windows up and down, slow and fast.
>I didn't experience any problem.
>
>I don't have emacs installed to try it.  Are you sure it is the
>WM_TAKE_FOCUS the problem and not some emacs setting trying to steal
>the focus what confuses cwm?
>Perhaps I don't understand what you mean.  I opened 15 xterms and
>seamonkey and cycled through windows up and down, slow and fast.
>I didn't experience any problem.

The speed is not a problem, since the bug is triggered because cwm raise
two windows in every cycle.
Just start the cycle with seamonkey selected, so it's always the previous
window.

>I don't have emacs installed to try it.  Are you sure it is the
>WM_TAKE_FOCUS the problem and not some emacs setting trying to steal
>the focus what confuses cwm?

It's also happens with firefox,

--
Ruben Miller
Reply | Threaded
Open this post in threaded view
|

Re: cwm 6.2: Windows losing focus while cycling (ALT-TAB)

Ruben Miller
In reply to this post by Ruben Miller
In article <CAEnp9CEpPEJxkWkxLu1qmP8qTA4Ti4+6hCFrGqYy1+WZ0dBy=[hidden email]>
Ruben Miller <[hidden email]> wrote:
>The speed is not a problem, since the bug is triggered because cwm raise
> two windows in every cycle.
> Just start the cycle with seamonkey selected, so it's always the previous
> window.

Just in case, the idea is cycling without releasing ALT, so the client with
WM_TAKE_FOCUS is always behind the new one.
--
Ruben Miller
Reply | Threaded
Open this post in threaded view
|

Re: cwm 6.2: Windows losing focus while cycling (ALT-TAB)

Walter Alejandro Iglesias-3
Hi Ruben,

In article <[hidden email]>
Ruben Miller <[hidden email]> wrote:
> In article <CAEnp9CEpPEJxkWkxLu1qmP8qTA4Ti4+6hCFrGqYy1+WZ0dBy=[hidden email]>
> Ruben Miller <[hidden email]> wrote:
> >The speed is not a problem, since the bug is triggered because cwm raise
> > two windows in every cycle.
> > Just start the cycle with seamonkey selected, so it's always the previous
> > window.
>
> Just in case, the idea is cycling without releasing ALT, so the client with
> WM_TAKE_FOCUS is always behind the new one.

First of all, I'm not a developer but since I made that diff I'm trying
to help.

No idea in which way it's related but I could easily reproduce the issue
you describe after setting back SNA acceleration in my xorg.conf (since
my graphic card has some issue with the default acceleration I have to
use UXA.)

Wait to Okan Demirmen (cwm maintainer) to get a good answer. :-)

Reply | Threaded
Open this post in threaded view
|

Re: cwm 6.2: Windows losing focus while cycling (ALT-TAB)

Walter Alejandro Iglesias-3
In reply to this post by Ruben Miller
Hi again Ruben,

To be sure, today I did again the same test I mentioned you with same
results.  While I can easly do it using the default SNA, *I can not
reproduce the bug using intel UXA acceleration*.  I see in your logs you
have an intel card, you can do this test yourself.  Restart X after
creating a /etc/xorg.conf:


# /etc/X11/xorg.conf
Section "ServerLayout"
        Identifier "X.org Configured"
        Screen 0 "Screen0" 0 0
EndSection

Section "Device"
        Identifier "Card0"
        Driver "intel"
        BusID "PCI:0:2:0"
        #Option "AccelMethod" "SNA"
        Option "AccelMethod" "UXA"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Card0"
        Monitor    "Monitor0"
        SubSection "Display"
                Viewport   0 0
                Depth     24
        EndSubSection
EndSection


And try to reproduce the bug.  Perhaps it's not just a cwm bug.


        Walter




Reply | Threaded
Open this post in threaded view
|

Re: cwm 6.2: Windows losing focus while cycling (ALT-TAB)

Ruben Miller
In reply to this post by Ruben Miller
>To be sure, today I did again the same test I mentioned you with same
> To be sure, today I did again the same test I mentioned you with same
> results. While I can easly do it using the default SNA, *I can not
> reproduce the bug using intel UXA acceleration*. I see in your logs you
> have an intel card, you can do this test yourself. Restart X after
> creating a /etc/xorg.conf:
> ...
>And try to reproduce the bug. Perhaps it's not just a cwm bug.

Yes, with UXA it took me between 50 and 60 cycles but I'm able to reproduce
the bug. While with SNA it's normally less than 5.
With SNA and the patch I put in the first email, after more than 200 cycles
the problem it's never shows.


--
Ruben Miller
Reply | Threaded
Open this post in threaded view
|

Re: cwm 6.2: Windows losing focus while cycling (ALT-TAB)

Walter Alejandro Iglesias-3
Hi Ruben,

In article <CAEnp9CH6=[hidden email]> Ruben Miller <[hidden email]> wrote:

> >To be sure, today I did again the same test I mentioned you with same
> > To be sure, today I did again the same test I mentioned you with same
> > results. While I can easly do it using the default SNA, *I can not
> > reproduce the bug using intel UXA acceleration*. I see in your logs you
> > have an intel card, you can do this test yourself. Restart X after
> > creating a /etc/xorg.conf:
> > ...
> >And try to reproduce the bug. Perhaps it's not just a cwm bug.
>
> Yes, with UXA it took me between 50 and 60 cycles but I'm able to reproduce
> the bug. While with SNA it's normally less than 5.

Then surely your video card behaves different to mine.  I promise
I insisted hard time trying to reproduce it.  I fact, lately I changed
back to fvwm2 but I was using cwm enough time to assure I would notice
this kind of issue (I'm a bit maniacal with these details :-)).

> With SNA and the patch I put in the first email, after more than 200 cycles
> the problem it's never shows.
>

Fine.  It only rests to wait Okan or someone else to check your patch
and commit it. :-)


Thanks!


Reply | Threaded
Open this post in threaded view
|

Re: cwm 6.2: Windows losing focus while cycling (ALT-TAB)

Ruben Miller
In reply to this post by Ruben Miller
On Wed 2018.01.10 at 13:12:04 -03 Okan Demirmen wrote:

> Hi Ruben - thanks for the report and apologies for the late response.
>
> Somehow I am unable to replicate this behaviour. Interestingly enough, I
> did change something in this area recently but somehow don't think that
> would have magically fixed what you are experiencing. When you say
> sometimes the active client misses the input focus, are you saying even
> the border isn't redraw and the client is not seeing the keyboard events
> (another client is)?
>
> Thanks,
> Okan
Hi Okan,

The border is redraw (client_setactive is called for the current client), but
the focus goes to the previous windows.

Thanks!
Ruben Miller.



Reply | Threaded
Open this post in threaded view
|

Re: cwm 6.2: Windows losing focus while cycling (ALT-TAB)

Ruben Miller
And yes, by losing focus I'm referring to the keyboard inputs.

2018-01-10 13:31 GMT-03:00 Ruben Miller <[hidden email]>:

> On Wed 2018.01.10 at 13:12:04 -03 Okan Demirmen wrote:
> > Hi Ruben - thanks for the report and apologies for the late response.
> >
> > Somehow I am unable to replicate this behaviour. Interestingly enough, I
> > did change something in this area recently but somehow don't think that
> > would have magically fixed what you are experiencing. When you say
> > sometimes the active client misses the input focus, are you saying even
> > the border isn't redraw and the client is not seeing the keyboard events
> > (another client is)?
> >
> > Thanks,
> > Okan
> Hi Okan,
>
> The border is redraw (client_setactive is called for the current client),
> but
> the focus goes to the previous windows.
>
> Thanks!
> Ruben Miller.
>
>
>
>


--
Ruben Miller
Reply | Threaded
Open this post in threaded view
|

Re: cwm 6.2: Windows losing focus while cycling (ALT-TAB)

Okan Demirmen
On Wed, Jan 10, 2018 at 11:40 AM, Ruben Miller <[hidden email]> wrote:
> And yes, by losing focus I'm referring to the keyboard inputs.

Still having trouble replicating this.

Are the clients that don't get input the ones with WM_TAKE_FOCUS or
the ones without it?

> 2018-01-10 13:31 GMT-03:00 Ruben Miller <[hidden email]>:
>>
>> On Wed 2018.01.10 at 13:12:04 -03 Okan Demirmen wrote:
>> > Hi Ruben - thanks for the report and apologies for the late response.
>> >
>> > Somehow I am unable to replicate this behaviour. Interestingly enough, I
>> > did change something in this area recently but somehow don't think that
>> > would have magically fixed what you are experiencing. When you say
>> > sometimes the active client misses the input focus, are you saying even
>> > the border isn't redraw and the client is not seeing the keyboard events
>> > (another client is)?
>> >
>> > Thanks,
>> > Okan
>> Hi Okan,
>>
>> The border is redraw (client_setactive is called for the current client),
>> but
>> the focus goes to the previous windows.
>>
>> Thanks!
>> Ruben Miller.
>>
>>
>>
>
>
>
> --
> Ruben Miller

Reply | Threaded
Open this post in threaded view
|

Re: cwm 6.2: Windows losing focus while cycling (ALT-TAB)

Ruben Miller
2018-01-10 13:55 GMT-03:00 Okan Demirmen <[hidden email]>:

>
> Are the clients that don't get input the ones with WM_TAKE_FOCUS or
> the ones without it?
>
> The ones without it.

--
Ruben Miller
Reply | Threaded
Open this post in threaded view
|

Re: cwm 6.2: Windows losing focus while cycling (ALT-TAB)

Okan Demirmen
On Wed, Jan 10, 2018 at 12:01 PM, Ruben Miller <[hidden email]> wrote:
> 2018-01-10 13:55 GMT-03:00 Okan Demirmen <[hidden email]>:
>>
>>
>> Are the clients that don't get input the ones with WM_TAKE_FOCUS or
>> the ones without it?
>>
> The ones without it.

I still can't reproduce this. From your first mail, I opened 10 xterms
in random locations, then an emacs window (has the WM_TAKE_FOCUS Atom,
and it's the active one), then I started cycling. No mater what client
I ended up on, it always has input focus, regardless of WM_TAKE_FOCUS
or not.

Is there a reliable way to duplicate the issue?

Reply | Threaded
Open this post in threaded view
|

Re: cwm 6.2: Windows losing focus while cycling (ALT-TAB)

Ruben Miller
Well, judging for the conversation that I had with Walter in this thread,
it's seems
that the bug is only shows in certain video card and configuration. I'm
using an
Ironlake (Arrandale) with the SNA backend. So maybe that's why you can
reproduce the thing.


2018-01-10 15:44 GMT-03:00 Okan Demirmen <[hidden email]>:

> On Wed, Jan 10, 2018 at 12:01 PM, Ruben Miller <[hidden email]>
> wrote:
> > 2018-01-10 13:55 GMT-03:00 Okan Demirmen <[hidden email]>:
> >>
> >>
> >> Are the clients that don't get input the ones with WM_TAKE_FOCUS or
> >> the ones without it?
> >>
> > The ones without it.
>
> I still can't reproduce this. From your first mail, I opened 10 xterms
> in random locations, then an emacs window (has the WM_TAKE_FOCUS Atom,
> and it's the active one), then I started cycling. No mater what client
> I ended up on, it always has input focus, regardless of WM_TAKE_FOCUS
> or not.
>
> Is there a reliable way to duplicate the issue?
>



--
Ruben Miller