[KScreen] [Bug 414866] Support per-screen scale factors on X11
https://bugs.kde.org/show_bug.cgi?id=414866 --- Comment #2 from Marc Streckfuß --- After reading through the patch, I think deferring the scaling to X11 could even remove all the downsides of the previous patch (it would work on all applications), but might introduce it's own set of problems: With my suggestion, all screens run at the same dpi and thus have their virtual space, this means panning and scales and fonts etc is all according to the highest DPI. For overlapping windows, there are no corner-cases, they just use the high DPI, as essentially all windows have the same DPI. X11 will then take the contents and scale the pixels down, this means the windows have the same size on all screens. Downside I see is: The applications all render at a higher resolution than needed, thus have an additional load. Then the scaling process might be lossy, so it looks worse than without a multi monitor setup. As such, images might get upscaled to the high resolution and X11 scales them down again. I have the feeling that my lower dpi monitor does look worse than it used before, but I guess we can't take that as true, as I never had a comparison and now that I got a better display, I can directly compare them and see how "bad" it really was. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 414866] New: Allow consistent DPI on Multi-DPI Setups using X11 Scaling
https://bugs.kde.org/show_bug.cgi?id=414866 Bug ID: 414866 Summary: Allow consistent DPI on Multi-DPI Setups using X11 Scaling Product: plasmashell Version: 5.12.9 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: marc.streckf...@gmail.com CC: plasma-b...@kde.org Target Milestone: 1.0 Flags: X11+ Apologies if something like this has already been fixed, I'm still on Kubuntu 18.04 LTS, thus it could well be that this has been addressed upstream, but I doubt that. Also sorry if this is the wrong component, I don't know which part is responsible for configuring X11. So, I had the problem of multiple DPI and read that X11 only supports on -dpi directive and that one should wait for wayland to support that. Fortunately I found a [blogpost](https://blog.summercat.com/configuring-mixed-dpi-monitors-with-xrandr.html) to use xrandr to configure X11 properly, so that it works on my system. It would thus be awesome if KDE could support either monitor-dependant scaling or some magic mode where dpi is set to the highest possible (thus increasing the virtual resolution of the other displays and then scaling down again). My example config is: ``` xrandr --dpi 108.8 --fb 3735x2880 --output HDMI-0 --scale 1.088x1.088 --rotate left --pos 0x160 --panning 1175x2089+0+0 --output DP-2.8 --mode 2560x1440 --pos 1175x1440 --panning 2560x1440+1175+1440 --output DVI-D-0 --scale 1.333x1.333 --pos 1175x0 --panning 2560x1440+1175+0 ``` The scale has been determined by dividing the individual DPI of the displays (DVI-D-0 is a Full HD Panel but with the scale we are at WQHD virtual again). SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 18.04 KDE Plasma Version: 5.12.9 KDE Frameworks Version: 5.44.0 Qt Version: 5.9.5 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 381480] Crash in in QQuickAnimatorProxyJob::sceneGraphInitialized
https://bugs.kde.org/show_bug.cgi?id=381480 --- Comment #17 from Marc Streckfuß --- Created attachment 112754 --> https://bugs.kde.org/attachment.cgi?id=112754&action=edit New crash information added by DrKonqi plasmashell (5.12.4) using Qt 5.9.5 - What I was doing when the application crashed: I can trigger this crash one out of 10 times approximately. When I wake up my machine from standby, the third screen is disabled, so after logging in, I open the Settings Panel, navigate to "Display", activate the screen and place it and I get the crash after clicking on "Apply". This currently happens in Kubuntu 18.04 (clean install was 16.10 back then), but I had the behavior (crashing settings panel) also in 17.10, but I can't verify if the stack trace looked equal. -- Backtrace (Reduced): #6 0x7f98cf403268 in QQuickAnimatorProxyJob::sceneGraphInitialized() () at /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5 #7 0x7f98cb8ec122 in QObject::event(QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x7f98cc8c482c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #9 0x7f98cc8cc0f4 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 #10 0x7f98cb8bc9a8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 381480] Crash in in QQuickAnimatorProxyJob::sceneGraphInitialized
https://bugs.kde.org/show_bug.cgi?id=381480 Marc Streckfuß changed: What|Removed |Added CC||marc.streckf...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 371955] KRunner crashes while searching
https://bugs.kde.org/show_bug.cgi?id=371955 Marc Streckfuß changed: What|Removed |Added CC||marc.streckf...@gmail.com --- Comment #2 from Marc Streckfuß --- #372606 and #374758 are duplicates of this bug. Using GDB and the Debug-Symbols I found out that the actual root of this is a corrupted MDB Database probably from Baloo. There are some forum posts that one should rename ~/.local/share/baloo which might trigger a rebuild. Also see #360946 talking about the fact that "Launching Konsole from KRunner" corrupts the database. This Corruption should not actually happen either. The Output from Krunner itself is: true true true session switching to "Disc" mdb.c:5697: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() The Backtrace: __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58 __GI_abort () at abort.c:89 ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 mdb_cursor_get () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 Baloo::PostingDB::prefixIter(QByteArray const&) () from /usr/lib/x86_64-linux-gnu/libKF5BalooEngine.so.5 Baloo::Transaction::postingIterator(Baloo::EngineQuery const&) const () from /usr/lib/x86_64-linux-gnu/libKF5BalooEngine.so.5 ?? () from /usr/lib/x86_64-linux-gnu/libKF5Baloo.so.5 ?? () from /usr/lib/x86_64-linux-gnu/libKF5Baloo.so.5 ?? () from /usr/lib/x86_64-linux-gnu/libKF5Baloo.so.5 Baloo::Query::exec() () from /usr/lib/x86_64-linux-gnu/libKF5Baloo.so.5 ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/krunner_baloosearchrunner.so ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/krunner_baloosearchrunner.so Plasma::AbstractRunner::performMatch ( this=0x564345d0, localContext=...) at ./src/abstractrunner.cpp:131 ThreadWeaver::Executor::run(QSharedPointer const&, ThreadWeaver::Thread*) () from /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 ThreadWeaver::Job::execute(QSharedPointer const&, ThreadWeaver::Thread*) () from /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 ThreadWeaver::Thread::run() () from /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 QThreadPrivate::start (arg=0x55dacf30) at thread/qthread_unix.cpp:341 start_thread (arg=0x7fffc0025700) at pthread_create.c:333 clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 So technically there are two bugs here: 1. Baloo not properly handling corrupted data sets (#360946 indicates that you can just skip that set). We have seen multiple error sources in MDB for that, so it's not just prefixIter() but rather at an early stage. 2. Baloo/Krunner corrupting that DataSet (#360946 saying that you can reproduce it by launching Konsole from Krunner). -- You are receiving this mail because: You are watching all bug changes.
