Hi all,

First of all, thanks for all of your hard work. KDE 5 seems very inviting, and I know it takes a lot of effort to get it to be so.

I'm using it on Ubuntu 15.04 (vivid) from the KDE ppa. When running konsole --version I get:
$ konsole --version
QCoreApplication::arguments: Please instantiate the QApplication object first
Qt: 5.4.1
KDE Frameworks: 5.12.0
Konsole: 15.04.0

My hardware is a Dell Latitude E7440 laptop with an Intel Corporation Haswell-ULT Integrated Graphics Controller. I sometimes run with the UXA workaround, and sometimes without, as I'm trying to check whether these problems are related.

Here is a list of my problems, and I'd love to know whether to open bugs for them:


Keyboard layout problems:
I have two layouts defined. Under certain conditions, they simply stop working. Sometimes the indicator isn't working, and sometimes XKB seems to lose the settings. Running setxkbmap sometimes restores the indicator, and sometimes not.

Two things that seem to trigger this situation (they are kind of the same thing, really) is if I unplug and replug the wireless mouse receiver dongle, and if I dock/undock the laptop (the docking station has a USB hub with external keyboard and mouse).


External display problems:
When I undock the computer, it sometimes fails to forget the external display. Similarly, if I dock it, it sometime fails to detect the external display. If I just run "xrandr", it sometimes, but not always, solves the problem. I found that making sure that the computer is always unsuspended before docking/undocking reduces/eliminates this problem. It seems like no rescan is done when the computer comes back from sleep.

Docking/undocking is also where most of the plasma crashes I've seen to date happen.

Also, it is very hard to control where new windows show up. They often come up on the wrong screen (i.e. - there is one screen where my mouse pointer is, where the click that opened the new window was put in, and where the parent window is, and then there is the other screen, where the new window shows up). This, annoyingly, frequently happens with the K menu and with various semi-transparent pop ups (i.e. - from the widgets). Sometimes, these widgets windows don't show up at all (they get focus, but are not visible on either screens).


Focus:
Asynchronous KDE pop ups should not steal focus, no matter what the focus stealing settings are. There is no reason for the notifications window to have focus, certainly not without me explicitly transferring focus to it.


Internal display problems:
When the lock screen is left to its own for a while, the screen blanks out completely. Moving the mouse or hitting the keyboard does not recover it. Pressing CTRL-ALT-F1 to get a shell does not work. What does work is to blindly type in my password, and then hit the keys for adjusting the screen brightness up. It seems the lock screen sets the brightness all the way down, but does not detect the activity that should have set it back up.



Bluetooth management:
Completely missing. It's not clear how to set up a phone for network sharing or file transfer (aside from KDE connect). Also, how to change the computer's name and sharing option.



KDE Connect:
I know, in relation to everything else in this post, this complaint is kind of petty. Still, this is an excellent idea that really needs a better implementation.

Mouse control needs a better way for right click. The standard for pads is a two fingers tap. The current menu option isn't something people would easily find. The two fingers drag to scroll, for example, works great.

The keyboard completely and utterly fails with non-English languages. This is a soft keyboard, and it should inject cooked, Unicode, characters, rather than physical keys. The current implementation tries to guess the physical key from the character passed by Android (fails if the Android keyboard isn't English), and then sends those as physical keys to the computer (issues the wrong character if the computer keyboard isn't English).

I know a lot of people have already asked for it, but a computer->phone keyboard is really really needed. I may try and implement one if I manage to find that mythical elusive creature called "free time".


All in all, great work, guys and gals. Keep up the good fight.

Shachar

expect this thread to be ignored - "my personal concern list" is completely unmaintanable and every discussion will become a mess.
Also it's pointless to report bugs *here*

Please report bugs against the buggy components: http://bugs.kde.org

luebking wrote:Please report bugs against the buggy components: http://bugs.kde.org

I'm quoting the sticky post titled IMPORTANT: How to report issues:

Always post your issues here before reporting a bug on KDE's bug tracker.

So, which is it?

Shachar

If you know there's a bug and you don't just fail to configure things, report a bug (or better: check bugzilla for duplicates first - you'll usually get a "likely" offer)

I'll briefly run over it:

> Keyboard layout problems:
Too unspecific about what the problem actually is (GUI button dead? fails reflection? doesn't apply to -some?- windows?)

> Two things that seem to trigger this situation
This however will create a new input device with basic settings from X11, ie. it's "normal" that you have to select a keyboard layout afterwards - I'm not sure whether the keyboard daemon (is enabled in "kcmshell5 kded"?) is supposed to catch this condition.

> External display problems:
Please check the KScreen bugzilla. Those bugs are reported.
POV: kscreen is completely unusable in its current state and the best thing one can do with it is to disable it.

> Docking/undocking is also where most of the plasma crashes I've seen to date happen.
Qt5 bug. Check https://bugs.kde.org/show_bug.cgi?id=341497 on details (The Qt bugs are linked there)

> This, annoyingly, frequently happens with the K menu and with various semi-transparent pop ups
That is not "windows" - these particular windows control where they want to show up. File a bugreport against plasma. It may be the plasmashell or the framework. It may even be QtQuick (I've never seen such and it requires more technical info)

KWin has different strategies to position new windows, "kcmshell5 kwinoptions"

> Focus:
Same component. Happens ever again since Plasma uses QML.
And no, they should not take the focus, but afair that was fixed (unless somebody changed the window type once more)
Your exact version of plasmashell is mandatory here. If it's recent. File a bug.

> Internal display problems:
Sounds like a driver bug.
The screen is suspended via xdpms. That should neither have impact on other virtual terminals (tried Ctrl+Alt+F2?) nor fail on input device action (X11 turns on the screen then, plasma/screenlocker has no deal in that)

No idea about bluetooth or kde connect, sorry.
For bluetooth you however need "bluedevil" and I don't know whether your distro provides the KF5 version (yet)

Thanks for the pointers.

luebking wrote:> Keyboard layout problems:
Too unspecific about what the problem actually is (GUI button dead? fails reflection? doesn't apply to -some?- windows?)

A little of all. Above all else, the problem is that XKB forgets the settings, and I cannot switch language any more. As I said, if I manually set a new set of XKB rules (using setxkbmap), this sometimes resolves the problem completely, and sometimes restores ability to switch, but the indicator does not change when the layout changes.

luebking wrote:> Two things that seem to trigger this situation
This however will create a new input device with basic settings from X11, ie. it's "normal" that you have to select a keyboard layout afterwards - I'm not sure whether the keyboard daemon (is enabled in "kcmshell5 kded"?) is supposed to catch this condition.

That doesn't sound right. As far as I know, the XKB settings are global, and not per-device at all. Something in the KDE framework is actively resetting the settings. I can try and run an X server with no window manager to verify, but I'd be very surprised if the behaviour is as you describe it.

luebking wrote:> Internal display problems:
Sounds like a driver bug.
The screen is suspended via xdpms. That should neither have impact on other virtual terminals (tried Ctrl+Alt+F2?) nor fail on input device action (X11 turns on the screen then, plasma/screenlocker has no deal in that)

I don't think it is. I think KDE is setting the backlight intensity to zero. As a result, I can switch to other VTs without a problem, but I cannot see what I'm doing there either. KDE does not support the hotkeys when the screen is locked. The backlight intensity hot-keys don't work over a virtual console anyways, so that part is not surprising.

I'll try to open bugs where appropriate.

Thanks,
Shachar

> I think KDE is setting the backlight intensity to zero.
Think based on what?
I checked the code, the screenlocker doesn't even incorporate dpms (and it does certainly not adjust display brightness)

I assume what happens instead is that powerdevil (check for power saving in system settings) lowers the screen brightness to the (configured) minimum after a (configured) time of inactivity.
I further assume that powerdevil relies on passive input grabs (seriously?) to notice when the user re-interacts with the system, so it can brighten up. Since all input is actively grabbed by the screenlocker (that's the major point of the locker), powerdevil could then not notice that it should brighten the screen.
I finally assume that your hardware has it's minimum possible brightness ("0") at indeed zero backlight. So setting the minimum value will not just darken but actually turn the screen off.

=> Check the screen brightness behavior in power saving, also run "xset dpms force off" and see whether you can get back access to your screen.

> As far as I know, the XKB settings are global
The settings are of course per-device, eg. I've a german and an english keyboard and a remote control and configured the layouts depending on the vendor in xorg.conf.d snippets. Also setskbmap has a "-device" switch. Omitting that just configures all devices at once.
Where did you read such misinformation?

> Something in the KDE framework is actively resetting the settings.
Maybe, but is very unlikely.
If you re-attach a device, it's configured by the defaults and/or matching xorg configs. Anything that had been applied at runtime (via eg. sexkbmap) is lost - that includes options like "grp:caps_toggle"

One might argue that the keyboard daemon (if running) should provide runtime support like what the server configs do (ie. you can configure special settings for special devices and when a matching device gets attached, the relevant settings are made for it)
I frankly don't know whether the keyboard daemon aims for such.

What should however totally *not* happen is that if you re-plug the mouse (the keyboard isn't bound to that dongle?) the keyboard changes. Is the keyboard wireless or wired?

For bluetooth, it is there, just not in System Settings, as kubuntu is having to use the KDE 4 version of Bluedevil in 15.04. Search for "blue" in the Kmenu, or go to Internet >> Bluedevil in the menu.

You will have to add bluedevil as an autostart item if you want it to load at login.