Hi everyone,
(please cc)
laptop: sony vaio vgn-z11
graphics hardware: GM45
X: 7.6 (Debian: 1:7.6+6)
X intel driver: 2:15.0 (Debian: 2:2.15.0-3)
system: Debian sid up2date
I regularly build kernels from git, but haven't tried a video projector
for some time now. I found that in recent kernels I have problems with
the output to the external screen.
After inital connection everything works and I have a BIG virtual
screen covering both units. Then I want to switch it to
Same image on both …
[View More]screens
and at that time one of the screens, most of the times the external
ones, sometimes both, fall into pieces with vertical stripes and
colors.
Waiting 25sec my program (xrandr or gnome screen props) resets the
setting and I am back to two screens showing independent images.
Is that a driver issue, a kernel issue, or anything else?
If you need more information, dmesg, X logs, or I should try some
patches, whatever please let me know.
Best wishes
Norbert
------------------------------------------------------------------------
Norbert Preining preining(a){jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
GLENWHILLY (n. Scots)
A small tartan pouch worn beneath the kilt during the thistle-harvest.
--- Douglas Adams, The Meaning of Liff
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
--
_______________________________________________
Dri-devel mailing list
Dri-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[View Less]
From: Michel Dänzer <daenzer(a)vmware.com>
This was based on a description by Ben Herrenschmidt:
> I've removed that SBA reset from the normal TLB invalidation path and
> left it only once after turning AGP on.
About six months ago, he said:
> I did it a bit differently, but yeah, you get the idea. I'm doing a
> patch series so don't bother pushing things too hard yet.
But I haven't seen anything from him about this since then, and people are
regularly hitting these …
[View More]lockups, so here we are...
Signed-off-by: Michel Dänzer <daenzer(a)vmware.com>
---
drivers/char/agp/uninorth-agp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index 47c2218..55af723 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -80,7 +80,7 @@ static void uninorth_tlbflush(struct agp_memory *mem)
ctrl | UNI_N_CFG_GART_INVAL);
pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL, ctrl);
- if (uninorth_rev <= 0x30) {
+ if (!mem && uninorth_rev <= 0x30) {
pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL,
ctrl | UNI_N_CFG_GART_2xRESET);
pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL,
--
1.7.5.1
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=26891
--- Comment #9 from shirk(a)bitspin.org 2011-05-19 06:22:52 PDT ---
(In reply to comment #8)
> Mine is [1002:6740] :
> [ 9.285052] [drm] Loading TURKS Microcode
>
> which kernel version are you using ?
2.6.39-rc7-00215-g194a526
git head with local patches applied (phys-efi, radeon-firmware hack)
I'm running Gentoo linux amd64.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are …
[View More]receiving this mail because: -------
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=26891
--- Comment #8 from Jérémy Lal <kapouer(a)melix.org> 2011-05-19 05:34:40 PDT ---
(In reply to comment #7)
> Since Jérémy has a working setup with GPU acceleration I can only suspect a
> problem in the microcode. iMac12,2 has a Radeon HD 6970M which utilizes the
> CAYMAN microcode while my Radeon HD6750M is using TURKS.
Mine is [1002:6740] :
[ 9.285052] [drm] Loading TURKS Microcode
which kernel version are you using ?
--…
[View More]
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[View Less]
Hi all,
One of the big issues we've been faced with at Linaro is around GPU
and multimedia device integration, in particular the memory management
requirements for supporting them on ARM. This next cycle, we'll be
focusing on driving consensus around a unified memory management
solution for embedded systems that support multiple architectures and
SoCs. This is listed as part of our working set of requirements for
the next six-month cycle (in spite of the URL, this is not being
…
[View More]treated as a graphics-specific topic - we also have participation from
multimedia and kernel working group folks):
https://wiki.linaro.org/Cycles/1111/TechnicalTopics/Graphics
I am working on getting the key technical decision makers to provide
input and participate in the requirements collection and design for a
unified solution. We had an initial birds-of-a-feather discussion at
the Embedded Linux Conference in San Francisco this past week to kick
off the effort in preparation for the first embedded-memory-management
mini-sprint in Budapest week of May 9th at Linaro@UDS. One of the
outcomes of the BoF was the need for a mailing list to coordinate
ideas, planning, etc. The subscription management for the list is
located at http://lists.linaro.org/mailman/listinfo/linaro-mm-sig.
The mini-summit in Budapest will have live audio and an IRC channel
for those that want to participate (details to go out on the list).
We expect to have additional summits over the course of the cycle,
with the next one likely at Linux Plumbers in September (though, I
would like to try for one more before then).
cheers,
Jesse
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=26891
--- Comment #7 from shirk(a)bitspin.org 2011-05-19 03:30:41 PDT ---
(In reply to comment #3)
> I'm booting an imac12,2 in UEFI mode (need a "Run EFI in physical mode" patch
> before doing so),
> here's how :
> 1) boot from latest ubuntu live CD (hold alt, or c, at boot)
> 2) dump the bios
> dd if=/dev/mem of=vbios.bin bs=65536 skip=12 count=1
> 3) move it to your partition's /lib/firmware/radeon/vbios.bin
> 4) use …
[View More]your patch, but move the radeon_read_bios_from_firmware
> call before all other calls to get the bios (force using vbios.bin)
>
Thats exactly what I did on my MBP however the screen flicker remains..
I'm pretty sure the BIOS is valid (dmesg identifies it as ATOM BIOS: Apple)
and strings revealed data like "Whistler Pro" which IIRC is the type code used
by
the Radeon HD 6xxx series.
Since Jérémy has a working setup with GPU acceleration I can only suspect a
problem in the microcode. iMac12,2 has a Radeon HD 6970M which utilizes the
CAYMAN microcode while my Radeon HD6750M is using TURKS.
So I'm stuck with working but non-accelerated radeondrmfb.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[View Less]