Hi Martin,
I'm trying to figure out how to ask X what color depth it is using...?
I think:
martin@merkaba:~> xdpyinfo | grep -i "depth of root"
depth of root window:24 planes
but am not completely sure.
This is thinkpad x60 with Debian 6.0.9.
AFAIK the 830GM chipset does not offer
Am Samstag, 21. Juni 2014, 22:29:01 schrieb Pavel Machek:
> Hi!
>
> I just test-booted 3.16-rc1, and background in X looked just wrong --
> very noticeable bands on the background gradient. I thought that maybe
> it is just my eyes, but I went back to older kernel, and background is
> ok now.
>
>
On Sat, Jun 21, 2014 at 10:29:01PM +0200, Pavel Machek wrote:
> Hi!
>
> I just test-booted 3.16-rc1, and background in X looked just wrong --
> very noticeable bands on the background gradient. I thought that maybe
> it is just my eyes, but I went back to older kernel, and background is
> ok now.
On Sat 2014-06-21 22:29:01, Pavel Machek wrote:
> Hi!
>
> I just test-booted 3.16-rc1, and background in X looked just wrong --
> very noticeable bands on the background gradient. I thought that maybe
> it is just my eyes, but I went back to older kernel, and background is
> ok now.
>
> I'm tryin
Hi!
I just test-booted 3.16-rc1, and background in X looked just wrong --
very noticeable bands on the background gradient. I thought that maybe
it is just my eyes, but I went back to older kernel, and background is
ok now.
I'm trying to figure out how to ask X what color depth it is using...?
T
In preparation for exporting very similar functionality through another
interface, gut the current remap_pfn_range(). The motivating factor here
is to reuse the PGB/PUD/PMD/PTE walker, but allow back progation of
errors rather than BUG_ON.
Signed-off-by: Chris Wilson
Cc: Andrew Morton
Cc: "Kiril
This is similar to remap_pfn_range(), and uses the recently refactor
code to do the page table walking. The key difference is that is back
propagates its error as this is required for use from within a pagefault
handler. The other difference, is that it combine the page protection
from io-mapping,
On an Ivybridge i7-3720qm with 1600MHz DDR3, with 32 fences,
Upload rate for 2 linear surfaces: 8134MiB/s -> 8154MiB/s
Upload rate for 2 tiled surfaces: 8625MiB/s -> 8632MiB/s
Upload rate for 4 linear surfaces: 8127MiB/s -> 8134MiB/s
Upload rate for 4 tiled surfaces: 8602MiB/s -> 8629MiB/s
Up
Currently, we only allocate a structure to hold metadata if we need to
allocate an ioremap for every access, such as on x86-32. However, it
would be useful to store basic information about the io-mapping, such as
its page protection, on all platforms.
Signed-off-by: Chris Wilson
Cc: linux...@kvac
