[kaffeine] [Bug 397594] Kaffeine plays video in a separate window under Wayland

2022-09-05 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=397594

Andrej Podzimek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||and...@podzimek.org
 Status|REPORTED|CONFIRMED

--- Comment #14 from Andrej Podzimek  ---
The title of this bug is quite an understatement; I think it should read
"Kaffeine is unusable under Wayland".

On ArchLinux with plasma-desktop 5.25.4, plasma-framework 5.97.0 and kaffeine
2.0.18, video appears (indeed) in a separate "VLC Player" window and resizing /
closing / manipulating that window is a recipe for an undefined state with
random Kaffeine crashes.

Apart from the video window problem, the UI is broken to a point where one
cannot (e.g.) select DVB-T channels, because the list of DVB-T channels
flickers, does not seem to respond to scrolling, shows random items that mostly
don't match the selected channel etc.

Someone suggested a "workaround" in the form of a different --platform, but
none of those that I tried worked, some segfault and as for 'xcb', the most
well-known one, that doesn't help either, because the UI looks disastrously bad
on my 300% scaled high-DPI setup. Basically each pixel of UI widgets is
stretched to 9 pixels (3x3) and, sadly enough, the same atrocious thing is done
to HD videos, i.e. they are scaled down to 1/3 of Kaffeine's real window
resolution.

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

[kwin] [Bug 427545] Dual DisplayPort monitors (tiled, MST, e.g. 5k) are not supported by KWin

2021-06-14 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=427545

--- Comment #3 from Andrej Podzimek  ---
For reference:
https://bugreports.qt.io/plugins/servlet/mobile#issue/QTBUG-65457

The recent Qt changes linked from the bug might be (very distantly) relevant
for this issue. (But this is likely not something that could be magically
solved by Qt alone.)

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

[kwin] [Bug 427545] Dual DisplayPort monitors (tiled, MST, e.g. 5k) are not supported by KWin

2021-05-09 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=427545

Andrej Podzimek  changed:

   What|Removed |Added

Version|5.19.5  |5.21.4

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

[kwin] [Bug 427545] Dual DisplayPort monitors (tiled, MST, e.g. 5k) are not supported by KWin

2021-05-09 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=427545

Andrej Podzimek  changed:

   What|Removed |Added

Summary|Dual DisplayPort monitors   |Dual DisplayPort monitors
   |(e.g. 5k) are not supported |(tiled, MST, e.g. 5k) are
   |correctly by KWin   |not supported by KWin

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

[kwin] [Bug 427545] Dual DisplayPort monitors (e.g. 5k) are not supported correctly by KWin

2021-04-29 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=427545

--- Comment #2 from Andrej Podzimek  ---
Even on 5.21 I still have no clue how to make this work. The problem with
setting the geometry is that windows don't seem to get maximized "for real"
(i.e. they keep their margins / decorations etc.) and full-screen video is not
treated nicely either.

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

[kwin] [Bug 427545] Dual DisplayPort monitors (e.g. 5k) are not supported correctly by KWin

2020-10-11 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=427545

Andrej Podzimek  changed:

   What|Removed |Added

Summary|Dual DisplayPort monitors   |Dual DisplayPort monitors
   |(e.g. 5k) are not supported |(e.g. 5k) are not supported
   ||correctly by KWin

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

[kwin] [Bug 427545] Dual DisplayPort monitors (e.g. 5k) are not supported

2020-10-11 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=427545

Andrej Podzimek  changed:

   What|Removed |Added

 CC||and...@podzimek.org

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

[kwin] [Bug 427545] New: Dual DisplayPort monitors (e.g. 5k) are not supported

2020-10-11 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=427545

Bug ID: 427545
   Summary: Dual DisplayPort monitors (e.g. 5k) are not supported
   Product: kwin
   Version: 5.19.5
  Platform: Archlinux Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: wayland-generic
  Assignee: kwin-bugs-n...@kde.org
  Reporter: and...@podzimek.org
  Target Milestone: ---

Created attachment 132274
  --> https://bugs.kde.org/attachment.cgi?id=132274=edit
Two 5k HP monitors (2 tiles each, quad 2560x2880 altogether) shown in
Systemsettings

SUMMARY

With both Wayland and X11, window maximization on dual DisplayPort monitors
doesn't work.
While the problem can be hacked around using hax11 on X11
(https://github.com/CyberShadow/hax11), there seems to be no solution for
Wayland.


STEPS TO REPRODUCE

1. Connect a dual DisplayPort monitor (sometimes called tiled); examples:
   * HP Z27q (a classical old 5k monitor)
   * LG 27MD5KL (a Thunderbolt 5k monitor with two virtual DisplayPorts/tiles)

2. Start KDE and maximize a window.


OBSERVED RESULT

Windows are maximized over a single 2560x2880 tile.
(While normal windows can be enlarged over both tiles manually, there is no way
to make full-screen video maximize correctly.)


EXPECTED RESULT

Windows (and full-screen videos) should be maximized over the entire 5120x2880
monitor.


SOFTWARE/OS VERSIONS

Linux/KDE Plasma: ArchLinux, kernel 5.8.14
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.74.0
Qt Version: 5.15.1


ADDITIONAL INFORMATION

This problem exists on all major GPUs (tried AMD (Radeon Pro W5700), Nvidia
(Quadro P5000)  Intel (UHD Graphics 620 in i7-8665U)).
X11 is affected in all 3 cases. Wayland is affected on Intel and AMD (and
doesn't work on NVidia).

For the record, a possible hax11 workaround for X11 is described at the bottom
of my comment here:
https://gitlab.freedesktop.org/drm/intel/-/issues/27#note_463683

Unfortunately, I haven't been able to find a workaround for kwin_wayland.

I tried KWin scripting, but that didn't work for multiple reasons:

1. workspace.clientList() contains a volatile list of 1-2 windows that seem to
be the Plasma desktop instances only, guessing from their
.geometry.{x,y,width,height}; no other windows are listed.

2. The geometry property appears to be clobbered:
   * It contains resolutions divided by the scaling factor (2), i.e., 1280x1440
instead of 2560x2880.
   * On a dual 5k layout (10240x2880 altogether, 5120x1440 when divided by 2,
the Wayland style), the 'x' property never exceeds 1280 (which it should
exceed, because the Plasma desktop appears on all 4 monitors (2 physical
monitors times 2 tiles)). (But there are at most 2 items in clientList() at all
times.)

3. This "reference" (well ... a list of identifiers), is very hard to follow:
https://techbase.kde.org/Development/Tutorials/KWin/Scripting/API_4.9 So there
may be a way to tell KWin how to maximize windows correctly, but I just
couldn't find it. A bit of advice would help a lot in this case.

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

[yakuake] [Bug 401982] One Wayland login cripples Yakuake in X11 forever

2019-05-12 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=401982

--- Comment #6 from Andrej Podzimek  ---
(In reply to Sebastian Krzyszkowiak from comment #5)
> Happens here as well. As a workaround, I do "xrandr -s 1" and then "xrandr
> -s 0", as screen resolution change seems to update Yakuake's geometry to a
> correct one.

This doesn't help in my case. After the two xrandr commands, Yakuake deploys
once, but only reaches 50% of the configured vertical size. Horizontal size and
position seems to be OK though. But afterwards it gets so broken that it
doesn't show up; once I hide Yakuake again, F12 has no visible effect any more,
even thought the process is still around.

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

[yakuake] [Bug 401982] One Wayland login cripples Yakuake in X11 forever

2019-03-10 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=401982

--- Comment #4 from Andrej Podzimek  ---
I'm still running into this with Yakuake 3.0.5.

This time I'm seeing it on my desktop, which has dual 5K (5120x2880). I was
shifting from ugly scaling tricks needeed ~2 years ago to a more contemporary
setup where Qt + Plasma just get things right.

Scaling factor 1 -> no issue with Yakuake.
Scaling factor 2 -> Yakuake says it has a 100% height, but is at 50%; width is
unaffected.
Scaling factor 3 -> Yakuake says it has a 100% height, but looks like 1/3;
width is unaffected.

This^^^ is slightly different from the dual 4K setup, in which case also width
was weird, Yakuake was not even centered etc.

I have the following variables set (out of which only the last one is probably
relevant for this case, I guess):

export GDK_SCALE=3
export GDK_DPI_SCALE=.33
export ELM_SCALE=3
export PLASMA_USE_QT_SCALING=1

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

[yakuake] [Bug 401982] One Wayland login cripples Yakuake in X11 forever

2019-02-24 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=401982

--- Comment #2 from Andrej Podzimek  ---
On what hardware? Are you using a high-DPI configuration? I think the problem
may only occurs on high-DPI.

In particular, I have the KDE scaling factor set to 3 (for 4K on 13") and I
also set this variable to make Plasma usable:

PLASMA_USE_QT_SCALING=1

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

[plasmashell] [Bug 402607] Dynamic scren layout changes don't work properly in Plasma

2019-01-02 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=402607

Andrej Podzimek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Resolution|WAITINGFORINFO  |---
 Status|NEEDSINFO   |CONFIRMED

--- Comment #7 from Andrej Podzimek  ---
Clearing the "needsinfo" flag.
Please let me know if there's any further information I can provide.

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

[plasmashell] [Bug 402607] Dynamic scren layout changes don't work properly in Plasma

2019-01-02 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=402607

--- Comment #6 from Andrej Podzimek  ---
Created attachment 117255
  --> https://bugs.kde.org/attachment.cgi?id=117255=edit
Broken Plasma dual-head desktop after monitor hot-plug

Unplugging and replugging the (Thunderbolt dock with an) external monitor
causes this. As you can see, the laptop screen is placed correctly (on the
right) and the mouse cursor (as well as windows) can be dragged there just
fine, but Plasma doesn't draw anything on the right (laptop, primary) screen
and leaves it black. No panels, no wallpaper. The left screen (external
monitor) now has *two* Plasma panels overlapping each other, which is really
quite annoying with auto-hide panels.

Killing Plasma and starting plasmashell again restores law and order (see
before_unplug.png for what that looks like).

Sometimes Plasma crashes on its own and gets restarted automatically during
monitor hotplugging. In that case the screen layout turns out to be fine,
presumably, but one gets an ugly error message in desktop notifications. The
ration between the broken layout in this screenshot and a Plasma crash is
(rough guess) 20:1, so the crash is very rare (and I don't have any dumps from
that or whatnot).

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

[plasmashell] [Bug 402607] Dynamic scren layout changes don't work properly in Plasma

2019-01-02 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=402607

--- Comment #5 from Andrej Podzimek  ---
Created attachment 117254
  --> https://bugs.kde.org/attachment.cgi?id=117254=edit
Normal Plasma single-head desktop

This occurs when the laptop either boots in single-head mode or the
(Thunderbolt dock with an) external monitor is unplugged. Everything looks /
works OK here, no duplicate overlapping control panels, no black screen,
windows are correctly relocated. Problems start after replugging the external
monitor (see after_replug.png).

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

[plasmashell] [Bug 402607] Dynamic scren layout changes don't work properly in Plasma

2019-01-02 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=402607

--- Comment #4 from Andrej Podzimek  ---
Created attachment 117253
  --> https://bugs.kde.org/attachment.cgi?id=117253=edit
Expected Plasma dual-head desktop

This is what the dual-head desktop should look like. It looks this way after a
normal login in dual-head mode. Unplugging and re-plugging the (Thunderbolt
dock with an) external monitor requires a Plasma restart to get back to this
state; otherwise a broken layout is shown (see after_replug.png).

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

[plasmashell] [Bug 402607] Dynamic scren layout changes don't work properly in Plasma

2019-01-02 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=402607

--- Comment #3 from Andrej Podzimek  ---
Created attachment 117252
  --> https://bugs.kde.org/attachment.cgi?id=117252=edit
xrandr -q with the laptop on Thunderbolt dock with a monitor

It's the same when the laptop boots with the Thunderbolt dock and when the dock
is unplugged and replugged.

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

[plasmashell] [Bug 402607] Dynamic scren layout changes don't work properly in Plasma

2019-01-02 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=402607

Andrej Podzimek  changed:

   What|Removed |Added

 CC||and...@podzimek.org

--- Comment #2 from Andrej Podzimek  ---
Created attachment 117250
  --> https://bugs.kde.org/attachment.cgi?id=117250=edit
xrandr -q with just the laptop

It's the same when the laptop boots without Thunderbolt and after Thunderbolt
gets unplugged.

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

[kleopatra] [Bug 282718] Kleopatra 2.1.1: Problems with importing and storing certificates

2018-12-27 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=282718

Andrej Podzimek  changed:

   What|Removed |Added

   Platform|Unlisted Binaries   |Archlinux Packages

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

[plasmashell] [Bug 402607] New: Dynamic scren layout changes don't work properly in Plasma

2018-12-27 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=402607

Bug ID: 402607
   Summary: Dynamic scren layout changes don't work properly in
Plasma
   Product: plasmashell
   Version: 5.14.4
  Platform: Archlinux Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Desktop Containment
  Assignee: se...@kde.org
  Reporter: and...@podzimek.org
CC: plasma-b...@kde.org
  Target Milestone: 1.0

SUMMARY
For the last ~8 years, Plasma has been responding incorrectly to desktop layout
changes, both manual ones as well as ones triggered by monitor hotplugging.


STEPS TO REPRODUCE
1. Install an external monitor and configure it to be on the left side of your
laptop's display.
2. Configure desktop settings in both situations (only the laptop display and a
full dual head setup).
3a. Unplug and re-plug the external monitor.
3b. Log in without the external monitor and then plug it in.


OBSERVED RESULT
Desktop, widgets and panels move from the primary (right) display to the
secondary (left, external) monitor. The primary display turns black. However,
it is positioned correctly within the virtual screen and working, i.e., the
mouse cursor moves into it and windows can be dragged and maximized there.
Panels from both the laptop display and the external monitor are incorrectly
covering each other and both placed on the external monitor. Killing and
restarting of plasmashell restores law and order (primary display is on the
laptop where it should be, secondary display has its custom configuration).


EXPECTED RESULT
Primary display should remain unchaged and settings previously used in a
particular dual-head desktop layout should be applied. No manual plasmashell
restart should ever be needed. The only situation in which the primary screen
layout should move to the external display is when an external monitor is
connected *and* the laptop lid is closed. It should never happen during
switches between the laptop display and dual-head with laptop display
configured as primary.


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: ArchLinux, kernel 4.19.12
KDE Plasma Version: 5.14.4
KDE Frameworks Version: 5.53.0
Qt Version: 5.12.0

ADDITIONAL INFORMATION
When the secondary monitor is placed on the right side of the primary monitor,
the problem sometimes doesn't occur. With the external monitor on the left,
it's 100% reproducible.

This has been a problem since ~2011, as far as I recall, but I thought I'd
report it at last.

This occurs on *all* of my laptops, on a 2009 Lenovo W510 with an NVidia GPU as
well as on a 2018 Dell XPS 13 with an Intel GPU.

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

[plasmashell] [Bug 402606] New: Desktop icons drag-and-drop problems

2018-12-27 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=402606

Bug ID: 402606
   Summary: Desktop icons drag-and-drop problems
   Product: plasmashell
   Version: 5.14.4
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Desktop Containment
  Assignee: se...@kde.org
  Reporter: and...@podzimek.org
CC: plasma-b...@kde.org
  Target Milestone: 1.0

SUMMARY
The drag-and-drop function for desktop icons is very unstable and hard to use;
mouse cursor randomly flashes between the "banned" cursor and a standard
dragging cursor during a drag.

STEPS TO REPRODUCE
1. Add a desktop icon.
2. Unlock widgets, unlock icon position.
3. Try to drag the icon to a new location.

OBSERVED RESULT
While dragging an icon to move it to a new location on the desktop, the cursor
randomly flashes and changes between the "banned" cursor and a normal dragging
cursor. Releasing the mouse button in the former situation cancels the icon
position change. Releasing the mouse button in the latter situation completes
the move.

EXPECTED RESULT
No "banned" cursor should ever be shown in this case. The possibility to move
icons should not randomly change with mouse cursor movement.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: ArchLinux, kernel 4.19.12
KDE Plasma Version: 5.14.4
KDE Frameworks Version: 5.53.0
Qt Version: 5.12.0

ADDITIONAL INFORMATION
This is a Dell XPS 13, 4K, dual head with an external 4K monitor on the left
side of the laptop display. This configuration may have some unexpected
effects. (Otherwise I think that even very rudimentary testing would have
revealed this obvious problem immediately.)

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

[plasmashell] [Bug 402606] Desktop icons drag-and-drop problems

2018-12-27 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=402606

Andrej Podzimek  changed:

   What|Removed |Added

 CC||and...@podzimek.org

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

[plasmashell] [Bug 402605] Widget locking and icon position locking has no effect on desktop icons

2018-12-27 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=402605

Andrej Podzimek  changed:

   What|Removed |Added

 CC||and...@podzimek.org

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

[plasmashell] [Bug 402605] New: Widget locking and icon position locking has no effect on desktop icons

2018-12-27 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=402605

Bug ID: 402605
   Summary: Widget locking and icon position locking has no effect
on desktop icons
   Product: plasmashell
   Version: 5.14.4
  Platform: Archlinux Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Desktop Containment
  Assignee: se...@kde.org
  Reporter: and...@podzimek.org
CC: plasma-b...@kde.org
  Target Milestone: 1.0

SUMMARY
Widget locking and icon position locking has no effect on desktop icons. Icons
can be moved freely, even when icon position is locked (using the right-button
menu) and even when widgets are locked.

STEPS TO REPRODUCE
1. Create a desktop icon.
2. Lock icon positions, lock widgets.
3. Move the desktop icon to a different place.

OBSERVED RESULT
Icon moves to the new location.

EXPECTED RESULT
Icon should not be movable at all or should jump back to its original location
upon mouse button release.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: ArchLinux, kernel 4.19.12
KDE Plasma Version: 5.14.4
KDE Frameworks Version: 5.53.0
Qt Version: 5.12.0

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

[kleopatra] [Bug 282718] Kleopatra 2.1.1: Problems with importing and storing certificates

2018-12-17 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=282718

Andrej Podzimek  changed:

   What|Removed |Added

 CC||and...@podzimek.org

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

[kdeconnect] [Bug 402246] Remote mouse cursor movement fails on multi-head layouts

2018-12-17 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=402246

Andrej Podzimek  changed:

   What|Removed |Added

 CC||and...@podzimek.org

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

[plasmashell] [Bug 402247] New: Touchscreen input interpreted incorrectly on multi-head setups

2018-12-17 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=402247

Bug ID: 402247
   Summary: Touchscreen input interpreted incorrectly on
multi-head setups
   Product: plasmashell
   Version: 5.14.4
  Platform: Archlinux Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Multi-screen support
  Assignee: aleix...@kde.org
  Reporter: and...@podzimek.org
CC: plasma-b...@kde.org
  Target Milestone: 1.0

STEPS TO REPRODUCE
1. With a touchscreen laptop, configure a multi-head setup with the laptop on
the right and an external (non-touch) monitor on the left.
2. Try to use the laptop's touchscren to control widgets located there.

OBSERVED RESULT
The touch location is interpreted as if the touchscreen covered the entire
width of the virtual screen with two displays. For example, a touch in the
middle of the laptop's touchscreen occurs (from Plasma's point of view) on the
borderline between the two displays, i.e., in the middle of the entire large
virtual screen.

EXPECTED RESULT
Touches should be interpreted only within the touchscreen that generates them;
a  single touchscreen's control input should never be stretched to cover an
entire virtual screen.

SOFTWARE/OS VERSIONS
Linux: 4.19.9 (ArchLinux)
KDE Plasma Version: 5.14.4
KDE Frameworks Version: 5.53.0
Qt Version: 5.12.0

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

[kdeconnect] [Bug 402246] New: Remote mouse cursor movement fails on multi-head layouts

2018-12-17 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=402246

Bug ID: 402246
   Summary: Remote mouse cursor movement fails on multi-head
layouts
   Product: kdeconnect
   Version: 1.3.3
  Platform: Archlinux Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: common
  Assignee: albertv...@gmail.com
  Reporter: and...@podzimek.org
  Target Milestone: ---

STEPS TO REPRODUCE
1. Set up a dual-head layout with primary display on the right.
2. Try to move your cursor using kdeconnect.

OBSERVED RESULT
Cursor moves correctly as long as it stays on the primary display. Moving to
the secondary display nails the cursor to the screen's furthest vertical edge
and one can no longer move the cursor horizontally from there.

EXPECTED RESULT
The cursor should move smoothly over both (all) screens.

SOFTWARE/OS VERSIONS
Linux: 4.19.9 (ArchLinux)
KDE Plasma Version: 5.14.4
KDE Frameworks Version: 5.53.0
Qt Version: 5.12.0

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

[yakuake] [Bug 401982] One Wayland login cripples Yakuake in X11 forever

2018-12-10 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=401982

Andrej Podzimek  changed:

   What|Removed |Added

 CC||and...@podzimek.org

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

[yakuake] [Bug 401982] New: One Wayland login cripples Yakuake in X11 forever

2018-12-10 Thread Andrej Podzimek
https://bugs.kde.org/show_bug.cgi?id=401982

Bug ID: 401982
   Summary: One Wayland login cripples Yakuake in X11 forever
   Product: yakuake
   Version: 3.0.5
  Platform: Archlinux Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: h...@kde.org
  Reporter: and...@podzimek.org
  Target Milestone: ---

Created attachment 116842
  --> https://bugs.kde.org/attachment.cgi?id=116842=edit
Screenshot of the crippled Yakuake window in X11 after Wayland has broken its
configuration somehow

SUMMARY

Yakuake window sizing gets utterly broken in X11 after using Yakuake once in a
Wayland session.

I suspect that this could be related/similar to
https://bugs.kde.org/show_bug.cgi?id=379919, but I'm not sure.

STEPS TO REPRODUCE
1. Log in to a Plasma (X11) workspace. Start Yakuake. [works fine] Log out.
2. Log in to a Plasma (Wayland) workspace. Start Yakuake. [works fine] Log out.
3. Log in to a Plasma (X11) workspace again. Start Yakuake. [looks crippled]

OBSERVED RESULT

Yakuake becomes a crippled tiny window in the top left corner of the screen.

EXPECTED RESULT

Yakuake should be centered and take up most of the screen width by default.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: ArchLinux, kernel 4.19.8
KDE Plasma Version: 5.14.4
KDE Frameworks Version: 5.53.0
Qt Version: 5.12.0

ADDITIONAL INFORMATION

This is a Dell XPS 13 with 4K resolution and the i915 module.

I tried to delete .config/konsolerc and .config/yakuakerc, but to no avail; one
single login into a Wayland session breaks Yakuake in X11 forever. I'm not sure
which settings are responsible for this and don't want to wipe out my entire
account. Other applications work normally in both Wayland and X11 (e.g. kwrite,
gwenview, chromium, pavucontrol, konsole).

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