[kwin] [Bug 452240] wayland: "No titlebar and frame" rule doesn't force SSDs

2022-04-03 Thread Subramaniyam Raizada
https://bugs.kde.org/show_bug.cgi?id=452240

Subramaniyam Raizada  changed:

   What|Removed |Added

 CC||k...@subraizada.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 452240] New: wayland: "No titlebar and frame" rule doesn't force SSDs

2022-04-03 Thread Subramaniyam Raizada
https://bugs.kde.org/show_bug.cgi?id=452240

Bug ID: 452240
   Summary: wayland: "No titlebar and frame" rule doesn't force
SSDs
   Product: kwin
   Version: 5.24.4
  Platform: Archlinux Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: rules
  Assignee: kwin-bugs-n...@kde.org
  Reporter: k...@subraizada.com
CC: isma...@gmail.com
  Target Milestone: ---

SUMMARY

I use the "No titlebar and frame": Force to "No" window rule to have KWin force
server side decorations on some applications which use CSD by default.

My rules were working in X11 - KWin would draw the titlebar above the
application's CSD and would draw the Breeze theme's window shadows around the
edges of the application. But the rules no longer work in Wayland.

I've tested that the "Keep above other windows" rule is still applying properly
to these applications in Wayland, so there's no issue with window matching.

I can apply the rule in the opposite direction to remove SSDs on normal Qt/GTK
applications like Konsole, Dolphin, Qalculate. That works fine in all
scenarios. So force-removing SSDs works, but force-adding them doesn't.


STEPS TO REPRODUCE
1. For an application which uses CSD, add a rule which has "No titlebar and
frame" set to "Force: No"
2. Run the application under an X11 session or in XWayland: the rule works. Run
the application under native Wayland: the rule has no effect.


OBSERVED RESULT
When the application is running under native Wayland, the application does not
have SSD applied by KWin. SSDs are drawn in X11 or when using XWayland.


EXPECTED RESULT
The application has server side decorations applied by KWin even in native
Wayland.


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3


ADDITIONAL INFORMATION

I tested this with Gnome's Simple-Scan (any other CSD-using Gnome application
should also reproduce) and also with some Electron applications.

Electron applications will run under XWayland by default, so this needs to be
added to the Exec line in their .desktop files to have them use native Wayland:
" --enable-features=UseOzonePlatform --ozone-platform=wayland".

Possibly related: https://bugs.kde.org/show_bug.cgi?id=429171

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 443129] 'Closeable' window rule does not work on Wayland

2022-04-03 Thread Subramaniyam Raizada
https://bugs.kde.org/show_bug.cgi?id=443129

Subramaniyam Raizada  changed:

   What|Removed |Added

 CC||k...@subraizada.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 443910] [Plasma 5.23] kwin_core: Failed to initialize compositing, compositing disabled

2021-10-23 Thread Subramaniyam Raizada
https://bugs.kde.org/show_bug.cgi?id=443910

Subramaniyam Raizada  changed:

   What|Removed |Added

 CC||k...@subraizada.com

--- Comment #15 from Subramaniyam Raizada  ---
I didn't find anything related to GLPlatformInterface or egl in my
~/.config/kwinrc.

However, the KWIN_OPENGL_INTERFACE environment variable was set to egl for me.
I didn't do anything to cause that; it seems to have automatically happened.

I was able to temporarily solve it with:
Within a terminal window inside the X session, run:
export KWIN_OPENGL_INTERFACE=glx
kwin_x11 --replace &
This obviously persists until you log out and start X again.

I tried adding GLPlatformInterface=glx inside the [Compositing] section of
kwinrc, but that didn't help - compositing was still broken after starting X
and required manually exporting the env variable and restarting kwin. Adding
the export command directly above 'exec startplasma-x11' in .xinitrc resulted
in the same outcome; it seems that the variable gets set to egl somewhere in
the plasma init sequence.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 417455] Black screen after SDDM login and start screen in 10bit/30bpp mode with compositor enabled in OpenGL mode (amdgpu)

2020-06-01 Thread Subramaniyam Raizada
https://bugs.kde.org/show_bug.cgi?id=417455

--- Comment #16 from Subramaniyam Raizada  ---
The issue is gone for me too on up-to-date Arch Linux, so it seems this is
fully resolved. Applications like Spectacle and VLC still have some fails with
10bpc, but KWin & compositing work with no issues.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 417455] Black screen after SDDM login and start screen in 10bit/30bpp mode with compositor enabled in OpenGL mode (amdgpu)

2020-05-22 Thread Subramaniyam Raizada
https://bugs.kde.org/show_bug.cgi?id=417455

--- Comment #8 from Subramaniyam Raizada  ---
Yes, based on my experience and what other comments have said, this is the
situation:

8 bit: Works fine in any configuration

10 bit AMDGPU: Works only with egl backend, compositing fails without
specifying egl. Appears to be a bug in the AMD drivers, because:

10 bit AMDGPU Pro: Works out of the box with the default backend. No idea how
this one works with egl.

Regardless, any 10bpc configuration causes issues with applications like VLC,
Chromium, etc. But those shouldn't be relevant here; KWin appears to be working
fine.

> What bothers me is that no one seems to show any interest in fixing them...
Given that this requires a relatively high-end monitor, and possibly also a
relatively high-end graphics card, to reproduce and most of the people working
on KWin aren't paid to do it, this isn't very surprising. You should bring this
up with the AMD and Chromium devs, they're the ones getting paid by AMD and
Google to make sure their products work well (unless 10bpc with/without egl
works fine in GNOME or another DE, in which case this is actually a KDE bug -
anyone want to test?).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 417455] Black screen after SDDM login and start screen in 10bit/30bpp mode with compositor enabled in OpenGL mode (amdgpu)

2020-02-28 Thread Subramaniyam Raizada
https://bugs.kde.org/show_bug.cgi?id=417455

Subramaniyam Raizada  changed:

   What|Removed |Added

 CC||k...@subraizada.com

--- Comment #4 from Subramaniyam Raizada  ---
I have the same issue on a 5700xt with AMDGPU - XRender works, OpenGL causes
black screen when compositing is enabled but cursor always works perfectly.
However with AMDGPU Pro the OpenGL backend works fine.

Plasma 5.18.2 (on Arch Linux)
Linux 5.5.6
amdgpu 19.1.0
andgpu-pro 19.30

AMDGPU Pro is a proprietary overlay on top of the FOSS AMDGPU driver that
provides 'enhanced' OpenGL/OpenCL/Vulkan implementations, for me I just had to
install the amdgpu-pro-libgl Arch AUR package to get the OpenGL part and make
kwin work.

With 10bpc AMDGPU and XRender text also gets purple fringing, noticeable in the
settings screen to change the compositing backend and also in other
applications like Dolphin. This doesn't happen at 8bpc with AMDGPU, or with
AMDGPU Pro on XRender or OpenGL at 10bpc. Overall it seems like there are
issues with the free AMD drivers, not with kwin.

-- 
You are receiving this mail because:
You are watching all bug changes.