User Details
- User Since
- Apr 21 2016, 2:20 PM (147 w, 6 d)
- Availability
- Available
Yesterday
Tue, Feb 19
Other aspect which is important to me long-term: is multi-GPU support of different vendors possible with the current patches or a separate backend? Current patches don't seem to allow that easily to add later on. Depending on DRM access in a separate backend it might be simpler to do later.
Right, but how is the way changed?
Other cases where the window geometry on the phone changes is when the screen is rotated or the virtual keyboard is pushing the window like @mart proposed
FYI there is previous discussion in T9780 in regards to touch window resize/move. The goal must be that whatever is he result here is usable in all IOUPs with primary or additional touch input. Therefore let us continue discussion there.
True. Anyway I'm not sure if changing the scale is something we want or if the KWin internal scale should really only be influenced by the resolution/size in a uniform way over all devices.
Because of the low to middle viewing distance and primary input device being keyboard and mouse the window border size can be "None" till "Normal". Currently it's "Normal" per default I believe but there was some discussion to set it to "None" in the past. Another topic is the buttons sizes, which is independent of this value.
I've created some sub-tasks to discuss definition of some common usage patterns we might want to concentrate first: Desktop, Phone, TV.
That's true. So the Wayland event message must be sent also on these hot-plug events or when the user does a manual override, what maybe warrants a separate protocol.
ping
The problem is not so easy to solve I believe now and needs a more holistic approach. Let's go back to the drawing board.
I only saw this commit now through other review.
One thing we should keep in mind: at some point we want multi-screen support on Plasma Mobile / convergence. For that we will probably just use KScreen as well.
Tue, Feb 12
Mon, Feb 11
Sat, Feb 9
First off: a driver not supporting Atomic Mode Setting is nothing modern. Does Nvidia has a plan to improve in this regard?
Impressive. Some small issues to resolve.
There are some open questions still:
- How to deal with desktop containments in a sensible way. With this patch applets and the launcher are moved above the virtual keyboard, which is already a great improvement. But we might want to deal with them in a more nicer way.
- Doe we want to expose the virtual keyboard position information somehow to the clients? The old text-input v2 protocol provided this information. We might want to let clients opt-in to not being size-changed, but placing the keyboard into their window instead at some proposed coordinates. I could imagine this could be nice on larger screens with multiple windows open. But this would need a text-input v4 protocol version or a separate protocol.
- Talking about multiple windows open: currently only the input focus window is moved. What's with other windows? I might be interested in them as well on a large screen while typing into the focused window.
Fri, Feb 8
Superseded by D17122.
Code looks fine. Scrolling through the git history, as Vlad said, the prefix should be [platforms/hwcomposer].
Wed, Feb 6
Tue, Feb 5
Thu, Jan 31
Mon, Jan 28
Context is missing. Do git diff -U 99999 to include it.
Fri, Jan 25
Let's test it on master then.
Thu, Jan 24
- Use QPainter render hint
- Remove ceil scale deduction
- rename Xwl arg according to fdo merge request change