[Bug 32556] screen flickers all the time with desktop image appearing only briefly
https://bugs.freedesktop.org/show_bug.cgi?id=32556 --- Comment #17 from Gildas Le Nadan <3ntr0p13 at gmail.com> 2010-12-23 23:51:50 PST --- Created an attachment (id=41407) --> (https://bugs.freedesktop.org/attachment.cgi?id=41407) registers with KMS patch and RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32556] screen flickers all the time with desktop image appearing only briefly
https://bugs.freedesktop.org/show_bug.cgi?id=32556 --- Comment #16 from Gildas Le Nadan <3ntr0p13 at gmail.com> 2010-12-23 23:50:31 PST --- (In reply to comment #13) > How about: > > pll->flags |= (RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER); > > Can you also attach a copy of your vbios? > (as root) > (use lspci to get the bus id) > cd /sys/bus/pci/devices/ > echo 1 > rom > cat rom > /tmp/vbios.rom > echo 0 > rom With this one screen is completely unusable (similar to the initial situation). Will attach kms_frac_closest.regs -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32619] [r600g] EE src/gallium/drivers/r600/r600_shader.c/r600_shader_from_tgsi:593 - unsupported token type 3
https://bugs.freedesktop.org/show_bug.cgi?id=32619 Dave Airlie changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Dave Airlie 2010-12-23 23:41:54 PST --- should be worked around now: http://cgit.freedesktop.org/mesa/mesa/commit/?id=876effb0e717e8e64050662f6ffa286c22065f5c -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32556] screen flickers all the time with desktop image appearing only briefly
https://bugs.freedesktop.org/show_bug.cgi?id=32556 --- Comment #15 from Gildas Le Nadan <3ntr0p13 at gmail.com> 2010-12-23 23:29:12 PST --- Created an attachment (id=41406) --> (https://bugs.freedesktop.org/attachment.cgi?id=41406) vbios.rom Here for Xmas, have a poodle vbios -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Freescale Linux BSP review
Alan,
I still stand by my assertion that educating companies as to the
realities and philosophies of open source is better than threatening them.
Your analogy of open source as a standard, a practical de facto standard
written in a programming language is a good one.Forking code (by never
upstreaming it) tends not to be sustainable (although some companies still
try).Proprietary code exists for all sorts of reasons, often a bogus belief
in an intrinsic value.Graphics, in particular, is a very litigious world
and also, the biggest cause of proprietary code, surely some link?
Back to the plot. Linaro is trying to help here, both in reducing
non-optimal code forking and in helping its members work better with the open
source communities. As I said in my earlier mail, this will take time. That
said, I've seen enormous shifts within the ARM partnership already this year
and look forward to more next year.
Merry Christmas / Happy Holidays to one and all.
Dave
ps nice to see that you keep your old email address.Are you still in Wales?
On 23 Dec 2010, at 17:17, Alan Cox wrote:
>> way to behave. The best way to get companies to change their behaviour is
>> to find them and support them. Making threatening GPL noises in email does
>> not help them in any way.
>
> I would disagree based on years of history.
>
> The best way to get a company to change behaviour is for a situation to
> occur in which it is in their own hardcore capitalist self interest to
> change.
>
> In my experience open source usually mirrors standards in this. The
> leading vendors refuse to take part, the smaller vendors see the
> opportunity - often working together - and the bigger vendor eithers gets
> its backside kicked or does a sharp turn in the right direction.
>
> That's the story of email, of the web, and is occuring currently in
> telephony and other areas.
>
> It's also why folks like Dell deserve a lot more credit than they get for
> the success of Linux.
>
> If its not commercially sensible it doesn't matter what the licensing
> says. They are corporations not charities, if it's not economically
> viable for them to manage it all themselves including new driver
> releases, legal risk, all their own review and keeping up with DRI then
> they have to decide which way to go - some go the "hit and run" approach
> ('not got kernel X then sorry but not our problem'), some do the work to
> support it release by release but don't go GPL (eg Nvidia), some open up,
> others just walk away.
>
> Alan
Freescale Linux BSP review
> way to behave. The best way to get companies to change their behaviour is
> to find them and support them. Making threatening GPL noises in email does
> not help them in any way.
I would disagree based on years of history.
The best way to get a company to change behaviour is for a situation to
occur in which it is in their own hardcore capitalist self interest to
change.
In my experience open source usually mirrors standards in this. The
leading vendors refuse to take part, the smaller vendors see the
opportunity - often working together - and the bigger vendor eithers gets
its backside kicked or does a sharp turn in the right direction.
That's the story of email, of the web, and is occuring currently in
telephony and other areas.
It's also why folks like Dell deserve a lot more credit than they get for
the success of Linux.
If its not commercially sensible it doesn't matter what the licensing
says. They are corporations not charities, if it's not economically
viable for them to manage it all themselves including new driver
releases, legal risk, all their own review and keeping up with DRI then
they have to decide which way to go - some go the "hit and run" approach
('not got kernel X then sorry but not our problem'), some do the work to
support it release by release but don't go GPL (eg Nvidia), some open up,
others just walk away.
Alan
[Bug 32619] New: [r600g] EE src/gallium/drivers/r600/r600_shader.c/r600_shader_from_tgsi:593 - unsupported token type 3
https://bugs.freedesktop.org/show_bug.cgi?id=32619 Summary: [r600g] EE src/gallium/drivers/r600/r600_shader.c/r600_shader_fro m_tgsi:593 - unsupported token type 3 Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: vlee at vmware.com mesa: 38eff56f7eb6c64b153d612ea6ae31bd78149a41 (master) chipset: RV620 system architecture: i686 libdrm-dev: 2.14.21-1ubuntu2.1 kernel version: 2.6.35-24-generic Linux distribution: Ubuntu 10.10 i386 Many piglit tests are now failing with one the following errors messages. EE src/gallium/drivers/r600/r600_shader.c/r600_shader_from_tgsi:593 - unsupported token type 3 EE src/gallium/drivers/r600/r600_shader.c/r600_pipe_shader_create:239 - translation from TGSI failed EE src/gallium/drivers/r600/r600_state.c/r600_draw_common:229 - missing vertex shader 07498075b5de14955958da44a90eb7ee203218a1 is the first bad commit commit 07498075b5de14955958da44a90eb7ee203218a1 Author: Dave Airlie Date: Sat Dec 18 10:36:55 2010 +1000 mesa/st: set the color write cbuf property for fragColor writes :04 04 c9f116d1716b9538f29e59f6d6495865a23c0c55 d11a15b189a4517423d87baefc0c06e4ed0f91bd Msrc bisect run success -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Freescale Linux BSP review
> The GPLv2 is written such that the "if you're interfacing the kernel > or compiler you don't need to opensource that bit with your app" I would suggest you re-read the license. It says nothing of the sort. Indeed the gcc compiler licensing for the compiler support library is actually rather carefully done for this reason. > You may think it's a horrible idea, and from a technical perspective > it is, but from a legal perspective.. it's not a problem. I would suggest you re-read the detail on derivative works, from a legal not a computer science point of view. You may want to read up on the history of the dispute between Next (the computing not the clothing firm) and the FSF with regards to the Objective C compiler. Note also btw that the possibility of accidentally including general user space was a concern which is why there is a rider with the kernel COPYING file - for the standard syscall interfaces only. There is a difference between a derivative work and merely using an interface and there are lots of ways works can be derivative or not that usually surprise people who think in models around code. The fact these can work in weird and wonderous ways is one reason for that rider. > grounds, and policy grounds. There is no legal issue here. It is not That is a point only a court of law can decide. It's something I do spend time discussing with lawyers and I have to say not one of them considers there to be no legal issue. The actual boundary for such things is extremely grey and ill defined in software, although there is a lot more caselaw in comparable other areas (anthologies and compilations versus for example music as film scores, or combining two pieces of music to make one tune) > concept now... what's the point? It'll never get into mainline. Unless it is open sourced - ditto the various other things with the same problem - including things like the Intel PSB driver. Alan
[PATCH] Update fbdev fb_fix_screeninfo
If you change the color depth via fbset or some other framebuffer aware
userland application struct fb_fix_screeninfo is not updated to this new
information. This patch fixes this issue. Also the function is changed to
just pass in struct drm_framebuffer so in the future we could use more
fields. I'm hoping some day fix->smem* could be set here :-)
Signed-off-by: James Simmons
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5c4f9b9..0307d60 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -607,6 +607,25 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
}
EXPORT_SYMBOL(drm_fb_helper_fini);
+void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer *fb)
+{
+ info->fix.type = FB_TYPE_PACKED_PIXELS;
+ info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
+ FB_VISUAL_TRUECOLOR;
+ info->fix.mmio_start = 0;
+ info->fix.mmio_len = 0;
+ info->fix.type_aux = 0;
+ info->fix.xpanstep = 1; /* doing it in hw */
+ info->fix.ypanstep = 1; /* doing it in hw */
+ info->fix.ywrapstep = 0;
+ info->fix.accel = FB_ACCEL_NONE;
+ info->fix.type_aux = 0;
+
+ info->fix.line_length = fb->pitch;
+ return;
+}
+EXPORT_SYMBOL(drm_fb_helper_fill_fix);
+
static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
u16 blue, u16 regno, struct fb_info *info)
{
@@ -816,6 +835,7 @@ int drm_fb_helper_set_par(struct fb_info *info)
mutex_unlock(>mode_config.mutex);
return ret;
}
+ drm_fb_helper_fill_fix(info, fb_helper->fb);
}
mutex_unlock(>mode_config.mutex);
@@ -953,6 +973,7 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper
*fb_helper,
if (new_fb) {
info->var.pixclock = 0;
+ drm_fb_helper_fill_fix(info, fb_helper->fb);
if (register_framebuffer(info) < 0) {
return -EINVAL;
}
@@ -979,26 +1000,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper
*fb_helper,
}
EXPORT_SYMBOL(drm_fb_helper_single_fb_probe);
-void drm_fb_helper_fill_fix(struct fb_info *info, uint32_t pitch,
- uint32_t depth)
-{
- info->fix.type = FB_TYPE_PACKED_PIXELS;
- info->fix.visual = depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
- FB_VISUAL_TRUECOLOR;
- info->fix.mmio_start = 0;
- info->fix.mmio_len = 0;
- info->fix.type_aux = 0;
- info->fix.xpanstep = 1; /* doing it in hw */
- info->fix.ypanstep = 1; /* doing it in hw */
- info->fix.ywrapstep = 0;
- info->fix.accel = FB_ACCEL_NONE;
- info->fix.type_aux = 0;
-
- info->fix.line_length = pitch;
- return;
-}
-EXPORT_SYMBOL(drm_fb_helper_fill_fix);
-
void drm_fb_helper_fill_var(struct fb_info *info, struct drm_fb_helper
*fb_helper,
uint32_t fb_width, uint32_t fb_height)
{
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 67738f3..701e830 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -150,7 +150,6 @@ static int intelfb_create(struct intel_fbdev *ifbdev,
// memset(info->screen_base, 0, size);
- drm_fb_helper_fill_fix(info, fb->pitch, fb->depth);
drm_fb_helper_fill_var(info, >helper, sizes->fb_width,
sizes->fb_height);
info->pixmap.size = 64*1024;
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 6d56a54..a26d047 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -359,7 +359,6 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo);
info->screen_size = size;
- drm_fb_helper_fill_fix(info, fb->pitch, fb->depth);
drm_fb_helper_fill_var(info, >helper, sizes->fb_width,
sizes->fb_height);
/* Set aperture base/size for vesafb takeover */
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c
b/drivers/gpu/drm/radeon/radeon_fb.c
index f7b4762..80c1c7a 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -225,8 +225,6 @@ static int radeonfb_create(struct radeon_fbdev *rfbdev,
strcpy(info->fix.id, "radeondrmfb");
- drm_fb_helper_fill_fix(info, fb->pitch, fb->depth);
-
info->flags = FBINFO_DEFAULT | FBINFO_CAN_FORCE_OUTPUT;
info->fbops = _ops;
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index f22e7fe..aac27bd 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -121,9 +121,6 @@ int drm_fb_helper_setcolreg(unsigned regno,
void drm_fb_helper_restore(void);
void drm_fb_helper_fill_var(struct fb_info *info, struct drm_fb_helper
*fb_helper,
Freescale Linux BSP review
On Mon, Dec 20, 2010 at 10:18:21AM -0600, Matt Sealey wrote: > Ownership of the code is dependent on who licensed it. I do not think > Linaro need be so concerned over opensourcing or reimplementing > drivers. The fact that the kernel driver is open source as it is, and > this is by far the most important part. The userspace library is > closed because it is proprietary; and I think it is well outside > Linaro's remit to lobby for opensourcing of proprietary code simply to > meet an esoteric and needless demand for source code access (as it > stands, you can get source code access by signing the usual plethora > of NDAs with the appropriate vendor, as Genesi has done). It is my > understanding that Freescale/AMD and Qualcomm maintain seperate forks > of the driver and do not cooperate on development, and in any case, > Linaro does not include Qualcomm anyway, therefore it is also to my > understanding that this discussion is also beyond Linaro's remit. Given that upstream policy is to refuse DRM components unless there's an open userspace consumer of the interface, whether or not this conversation has any purpose is entirely down to whether Linaro's kernel policy is to limit itself to upstreamable code or not. If Linaro's reference kernel is intended to include nothing but code that's on track to become mainline then asking whether there's any way these drivers can be merged is a useful question. If Linaro's reference kernel is intended to include whatever's necessary to get hardware working, upstream-suitable or otherwise, then there's not much point in worrying about it. -- Matthew Garrett | mjg59 at srcf.ucam.org
[git pull] drm fixes
On Thu, Dec 23, 2010 at 1:54 PM, Linus Torvalds wrote: > On Wed, Dec 22, 2010 at 8:59 AM, Chris Wilson > wrote: >> On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai wrote: >>> The commit 448f53a1ede54eb854d036abf54573281412d650 >>> ? drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks >>> >>> causes a regression on a SandyBridge machine here. >>> The laptop display (LVDS) becomes blank. ?Reverting the commit fixes >>> the problem. >> >> The question is whose BIOS is wrong? > > I don't think so. > >> ? ? ? ? ? ? ? ? ? ? ? ? The Lenovo U160's or the >> Sandybridge SDV? And why does it work for that other OS? > rhetorical question of the day here.> > > Quite frankly, I don't think the question should *ever* be "whose BIOS > is wrong?" > > You should always take for granted that the BIOS is wrong. It's not a > question of "blame the BIOS", it's a question of facts of life. > > It's 100% pointless to point fingers and say "the HP BIOS is wrong" or > "the Lenovo BIOS is wrong". Buggy BIOSes happen. ALWAYS. Any code that > relies on the BIOS to such a degree that it either works or not based > on it is by definition broken. > > Why does that code need to figure out some LVDS clock from the BIOS? > Why can't the code look at the actual hardware state or similar, since > presumably the screen is on after boot. THAT we can rely on, since a > BIOS that doesn't initialize LVDS is not going to ever ship even as > pre-release. > I've no idea but since this is spread-spectrum related the bios may not enable spread-spectrum on the panel, though really the question is as always, what does Windows do. Dave. > ? ? ? ? ? ? ? ? ? ? ? ?Linus > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[Bug 30131] Command & Conquer 3 crashes with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=30131 Pavel Ondra?ka changed: What|Removed |Added CC||drakkk at centrum.cz --- Comment #11 from Pavel Ondra?ka 2010-12-23 13:26:15 PST --- > Are there any other debug settings which I can turn on, which could help you > identifying the cause of the crash? You may find some useful info about obtaining backtraces with Wine here: http://wiki.winehq.org/Backtraces -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30131] Command & Conquer 3 crashes with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=30131 --- Comment #10 from Martin Stolpe 2010-12-23 12:40:36 PST --- (In reply to comment #9) > Then you are most probably using direct rendering. Could you possibly obtain a > backtrace (i.e. call stack) of the crash? I've tried to switch on wine_d3d, x11drv, x11settings, xrandr, xrender and xvidmode debug channels in wine, but the resulting log file doesn't seem to give any hints about the error (if you're interested I can upload the log file). Are there any other debug settings which I can turn on, which could help you identifying the cause of the crash? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32556] screen flickers all the time with desktop image appearing only briefly
https://bugs.freedesktop.org/show_bug.cgi?id=32556 --- Comment #14 from Alex Deucher 2010-12-23 11:07:39 PST --- Also try: pll->flags |= (RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER | RADEON_PLL_NO_ODD_POST_DIV); -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 32556] screen flickers all the time with desktop image appearing only briefly
https://bugs.freedesktop.org/show_bug.cgi?id=32556 --- Comment #13 from Alex Deucher 2010-12-23 10:49:28 PST --- How about: pll->flags |= (RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER); Can you also attach a copy of your vbios? (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/ echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[git pull] drm fixes
On Thu, Dec 23, 2010 at 04:54, Linus Torvalds wrote: > Why does that code need to figure out some LVDS clock from the BIOS? > Why can't the code look at the actual hardware state or similar, since > presumably the screen is on after boot. THAT we can rely on, since a > BIOS that doesn't initialize LVDS is not going to ever ship even as > pre-release. What if the system booted with it's display turned off? Like a closed laptop lid or disconnected monitor?
[git pull] drm fixes
On Thu, Dec 23, 2010 at 1:32 AM, Alex Riesen wrote: > On Thu, Dec 23, 2010 at 04:54, Linus Torvalds > wrote: >> Why does that code need to figure out some LVDS clock from the BIOS? >> Why can't the code look at the actual hardware state or similar, since >> presumably the screen is on after boot. THAT we can rely on, since a >> BIOS that doesn't initialize LVDS is not going to ever ship even as >> pre-release. > > What if the system booted with it's display turned off? Like a closed > laptop lid or disconnected monitor? So then we might have to guess and even use the BIOS state for guessing. But what's so hard to understand about that word "guess"? That really is what happens every single time you use some BIOS table. It's not "look up". It's not "get the right data". It very much is all about "guessing". The BIOS tables are invariably buggy, and have likely only ever been tested with one particular version of Windows. And that's _especially_ true of something like VBIOS tables. They haven't been tested even with windows, they have only been tested with the particular graphics driver that the vendor shipped with that machine. It's quite possible - even likely - that the graphics driver hard-codes something. So think about it - if we boot with the laptop open, you have two choices: "ask the hardware for real working state" or "guess by probing random state from the BIOS that may or may not actually ever be used that way by anything". Which choice would you pick? And if that means that some laptops have to be booted with the lid open, that really isn't a problem. And yes, I do realize that VGA traditionally has had lots of hardware state that is write-only and cannot be read back. It's possible that this case is one of those. I dunno. I hope not. (Side note: resume is different from boot. You should test that resume works with the lid closed, because resume state is not at all guaranteed to be sane at all, lid or no lid. But the way to fix that is NOT to ask the BIOS, it's to remember the state from the original boot from before the suspend). Linus
[git pull] drm fixes
On Wed, 22 Dec 2010 19:54:31 -0800 Linus Torvalds wrote: > > The Lenovo U160's or the > > Sandybridge SDV? And why does it work for that other OS? > rhetorical question of the day here.> > > Quite frankly, I don't think the question should *ever* be "whose BIOS > is wrong?" > > You should always take for granted that the BIOS is wrong. It's not a > question of "blame the BIOS", it's a question of facts of life. > > It's 100% pointless to point fingers and say "the HP BIOS is wrong" or > "the Lenovo BIOS is wrong". Buggy BIOSes happen. ALWAYS. Any code that > relies on the BIOS to such a degree that it either works or not based > on it is by definition broken. > > Why does that code need to figure out some LVDS clock from the BIOS? > Why can't the code look at the actual hardware state or similar, since > presumably the screen is on after boot. THAT we can rely on, since a > BIOS that doesn't initialize LVDS is not going to ever ship even as > pre-release. Oh I wish we could just do that. Strictly speaking though this isn't so much of a BIOS issue as it is a ROM issue. Platform vendors provide no way of getting at platform configuration details related to graphics aside from the tables they flash into ROM along with the VBIOS. The tables are just like an EDID ROM on a display: they communicate data we have no other way of getting. In the particular case of SSC, there's a board down spread spectrum clock reference source at a fixed frequency. We can't automatically determine it at runtime (asking the user "can you see this" at boot time isn't really an option), so we need to rely on the VBT to tell us. The Windows driver uses this data as well, but obviously either it's incorrect on our SDV (possible) or we're failing to parse the data correctly (likely). It's also possible we're failing to look at a bit that says "use/don't use SSC on this platform" making the frequency field meaningless. We'll figure it out or disable SSC enabling altogether failing that (risking interference with other components like wireless and sound). -- Jesse Barnes, Intel Open Source Technology Center
[Bug 32544] [r300g] LLVM support for software TLS implementation doesn't work
https://bugs.freedesktop.org/show_bug.cgi?id=32544 --- Comment #2 from Drill 2010-12-23 08:51:05 PST --- (In reply to comment #1) > I don't have a problem with r300g/LLVM. > > Could you possibly bisect the issue on your machine? Unfortunately can't imagine how to do this at the moment. The strange thing, is that i compile and use the old git version (from 15.11.2010) version in absolutely the same environment as the newest one git version with the same options. But, as already mentioned, i'm getting on old 800 fps, and only 250 on new one :( Forget to mention before - i'm using llvm 2.8 . -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
VERY slow scrolling on radeon graphics card: debugging a timing issue?
On 12/23/2010 02:25 AM, Michel D?nzer wrote: > On Mit, 2010-12-22 at 05:55 -0500, Mark Hounschell wrote: >> >> I also see this very problem on several machines I have with radeon video. >> For me the worst part is using vi in a konsole. Moving the cursor around >> is so slow that I just can't use these machines directly and have to ssh >> into them from another machine just to work on them. > > That's not the same problem as the one described by Michael, which is > about the console on virtual terminals different from X. > > For your problem, try choosing a different font (a fontconfig one > instead of a legacy X one) in konsole. > > Hum, but I do in fact see the same thing he sees on a VT. A dmesg command from a VT takes around 20 seconds to display. The same in a konsole takes a fraction of a second. So your probably right that my vi problem in a konsole is a different issue. I do see the same thing as the OP does though. I just figured they were probably related. Changing fonts doesn't change anything though. I normally use the "Misc Console" font FWIW. Regards Mark
[git pull] drm fixes
Linus Torvalds wrote: > You should always take for granted that the BIOS is wrong. Better yet, that there is no BIOS. Maybe one happy day, in the future. //Peter
Freescale Linux BSP review
> > I'm not advocating that closed source drivers be included in the > kernel, but IMHO, > having an open kernel-space driver would also help the reverse engineering > process at the same time as allowing common users as well as developers to > use and test any 3D applications -don't forget that 3D problems don't > end at the driver, > rather the opposite. Again thats a short-term view. So we spend the effort to clean up the open kernel code, but the vendors want to keep the interface to userspace the same so the binary modules can keep functioning? How do we clean up insanities in the interfaces? How do we optimise the stack going forward? Having the code in mainline won't help anyone who is any good at reverse engineering. Dave.
[Bug 30131] Command & Conquer 3 crashes with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=30131 --- Comment #9 from Marek Ol??k 2010-12-23 04:37:22 PST --- Then you are most probably using direct rendering. Could you possibly obtain a backtrace (i.e. call stack) of the crash? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30131] Command & Conquer 3 crashes with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=30131 --- Comment #8 from Martin Stolpe 2010-12-23 04:25:51 PST --- Hello Marek, (In reply to comment #7) > The game should not crash the X server. It doesn't crash the X server. The game tries to start but it will crash right before it is supposed to switch to the graphical full screen mode. > indirect rendering, which might happen with 32-bit apps on x86_64 systems. The system is a 32 bit system > Indirect rendering is buggy, slow, contains only a subset of features r300g > offers, and gets very little testing AFAIK. So please make sure the game uses > direct rendering. I should mention that using a 32-bit system may help. Where can I check what type of rendering I'm using. Should it be mentioned in the Xorg.log? I'm not at the system right now so I can't look. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Freescale Linux BSP review
Le mercredi 22 d?cembre 2010 ? 15:29 -0500, Nicolas Pitre a ?crit : > It is > not economically viable for the Open Source community to accommodate > proprietary drivers, irrespective of how loud you might advocate for > that. I think you can remove the word "economically" from your sentence (or replace it with e.g. "technically"), and it's all the more true. Xav
Re: [git pull] drm fixes
On Thu, Dec 23, 2010 at 04:54, Linus Torvalds torva...@linux-foundation.org wrote: Why does that code need to figure out some LVDS clock from the BIOS? Why can't the code look at the actual hardware state or similar, since presumably the screen is on after boot. THAT we can rely on, since a BIOS that doesn't initialize LVDS is not going to ever ship even as pre-release. What if the system booted with it's display turned off? Like a closed laptop lid or disconnected monitor? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30131] Command Conquer 3 crashes with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=30131 --- Comment #8 from Martin Stolpe martinsto...@gmail.com 2010-12-23 04:25:51 PST --- Hello Marek, (In reply to comment #7) The game should not crash the X server. It doesn't crash the X server. The game tries to start but it will crash right before it is supposed to switch to the graphical full screen mode. indirect rendering, which might happen with 32-bit apps on x86_64 systems. The system is a 32 bit system Indirect rendering is buggy, slow, contains only a subset of features r300g offers, and gets very little testing AFAIK. So please make sure the game uses direct rendering. I should mention that using a 32-bit system may help. Where can I check what type of rendering I'm using. Should it be mentioned in the Xorg.log? I'm not at the system right now so I can't look. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30131] Command Conquer 3 crashes with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=30131 --- Comment #9 from Marek Olšák mar...@gmail.com 2010-12-23 04:37:22 PST --- Then you are most probably using direct rendering. Could you possibly obtain a backtrace (i.e. call stack) of the crash? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Freescale Linux BSP review
On Mon, Dec 20, 2010 at 10:18:21AM -0600, Matt Sealey wrote: Ownership of the code is dependent on who licensed it. I do not think Linaro need be so concerned over opensourcing or reimplementing drivers. The fact that the kernel driver is open source as it is, and this is by far the most important part. The userspace library is closed because it is proprietary; and I think it is well outside Linaro's remit to lobby for opensourcing of proprietary code simply to meet an esoteric and needless demand for source code access (as it stands, you can get source code access by signing the usual plethora of NDAs with the appropriate vendor, as Genesi has done). It is my understanding that Freescale/AMD and Qualcomm maintain seperate forks of the driver and do not cooperate on development, and in any case, Linaro does not include Qualcomm anyway, therefore it is also to my understanding that this discussion is also beyond Linaro's remit. Given that upstream policy is to refuse DRM components unless there's an open userspace consumer of the interface, whether or not this conversation has any purpose is entirely down to whether Linaro's kernel policy is to limit itself to upstreamable code or not. If Linaro's reference kernel is intended to include nothing but code that's on track to become mainline then asking whether there's any way these drivers can be merged is a useful question. If Linaro's reference kernel is intended to include whatever's necessary to get hardware working, upstream-suitable or otherwise, then there's not much point in worrying about it. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Freescale Linux BSP review
The GPLv2 is written such that the if you're interfacing the kernel or compiler you don't need to opensource that bit with your app I would suggest you re-read the license. It says nothing of the sort. Indeed the gcc compiler licensing for the compiler support library is actually rather carefully done for this reason. You may think it's a horrible idea, and from a technical perspective it is, but from a legal perspective.. it's not a problem. I would suggest you re-read the detail on derivative works, from a legal not a computer science point of view. You may want to read up on the history of the dispute between Next (the computing not the clothing firm) and the FSF with regards to the Objective C compiler. Note also btw that the possibility of accidentally including general user space was a concern which is why there is a rider with the kernel COPYING file - for the standard syscall interfaces only. There is a difference between a derivative work and merely using an interface and there are lots of ways works can be derivative or not that usually surprise people who think in models around code. The fact these can work in weird and wonderous ways is one reason for that rider. grounds, and policy grounds. There is no legal issue here. It is not That is a point only a court of law can decide. It's something I do spend time discussing with lawyers and I have to say not one of them considers there to be no legal issue. The actual boundary for such things is extremely grey and ill defined in software, although there is a lot more caselaw in comparable other areas (anthologies and compilations versus for example music as film scores, or combining two pieces of music to make one tune) concept now... what's the point? It'll never get into mainline. Unless it is open sourced - ditto the various other things with the same problem - including things like the Intel PSB driver. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: VERY slow scrolling on radeon graphics card: debugging a timing issue?
On 12/23/2010 02:25 AM, Michel Dänzer wrote: On Mit, 2010-12-22 at 05:55 -0500, Mark Hounschell wrote: I also see this very problem on several machines I have with radeon video. For me the worst part is using vi in a konsole. Moving the cursor around is so slow that I just can't use these machines directly and have to ssh into them from another machine just to work on them. That's not the same problem as the one described by Michael, which is about the console on virtual terminals different from X. For your problem, try choosing a different font (a fontconfig one instead of a legacy X one) in konsole. Hum, but I do in fact see the same thing he sees on a VT. A dmesg command from a VT takes around 20 seconds to display. The same in a konsole takes a fraction of a second. So your probably right that my vi problem in a konsole is a different issue. I do see the same thing as the OP does though. I just figured they were probably related. Changing fonts doesn't change anything though. I normally use the Misc Console font FWIW. Regards Mark ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes
On Wed, 22 Dec 2010 19:54:31 -0800 Linus Torvalds torva...@linux-foundation.org wrote: The Lenovo U160's or the Sandybridge SDV? And why does it work for that other OS? Insert rhetorical question of the day here. Quite frankly, I don't think the question should *ever* be whose BIOS is wrong? You should always take for granted that the BIOS is wrong. It's not a question of blame the BIOS, it's a question of facts of life. It's 100% pointless to point fingers and say the HP BIOS is wrong or the Lenovo BIOS is wrong. Buggy BIOSes happen. ALWAYS. Any code that relies on the BIOS to such a degree that it either works or not based on it is by definition broken. Why does that code need to figure out some LVDS clock from the BIOS? Why can't the code look at the actual hardware state or similar, since presumably the screen is on after boot. THAT we can rely on, since a BIOS that doesn't initialize LVDS is not going to ever ship even as pre-release. Oh I wish we could just do that. Strictly speaking though this isn't so much of a BIOS issue as it is a ROM issue. Platform vendors provide no way of getting at platform configuration details related to graphics aside from the tables they flash into ROM along with the VBIOS. The tables are just like an EDID ROM on a display: they communicate data we have no other way of getting. In the particular case of SSC, there's a board down spread spectrum clock reference source at a fixed frequency. We can't automatically determine it at runtime (asking the user can you see this at boot time isn't really an option), so we need to rely on the VBT to tell us. The Windows driver uses this data as well, but obviously either it's incorrect on our SDV (possible) or we're failing to parse the data correctly (likely). It's also possible we're failing to look at a bit that says use/don't use SSC on this platform making the frequency field meaningless. We'll figure it out or disable SSC enabling altogether failing that (risking interference with other components like wireless and sound). -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Freescale Linux BSP review
way to behave. The best way to get companies to change their behaviour is
to find them and support them. Making threatening GPL noises in email does
not help them in any way.
I would disagree based on years of history.
The best way to get a company to change behaviour is for a situation to
occur in which it is in their own hardcore capitalist self interest to
change.
In my experience open source usually mirrors standards in this. The
leading vendors refuse to take part, the smaller vendors see the
opportunity - often working together - and the bigger vendor eithers gets
its backside kicked or does a sharp turn in the right direction.
That's the story of email, of the web, and is occuring currently in
telephony and other areas.
It's also why folks like Dell deserve a lot more credit than they get for
the success of Linux.
If its not commercially sensible it doesn't matter what the licensing
says. They are corporations not charities, if it's not economically
viable for them to manage it all themselves including new driver
releases, legal risk, all their own review and keeping up with DRI then
they have to decide which way to go - some go the hit and run approach
('not got kernel X then sorry but not our problem'), some do the work to
support it release by release but don't go GPL (eg Nvidia), some open up,
others just walk away.
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Freescale Linux BSP review
Alan,
I still stand by my assertion that educating companies as to the
realities and philosophies of open source is better than threatening them.
Your analogy of open source as a standard, a practical de facto standard
written in a programming language is a good one.Forking code (by never
upstreaming it) tends not to be sustainable (although some companies still
try).Proprietary code exists for all sorts of reasons, often a bogus belief
in an intrinsic value.Graphics, in particular, is a very litigious world
and also, the biggest cause of proprietary code, surely some link?
Back to the plot. Linaro is trying to help here, both in reducing
non-optimal code forking and in helping its members work better with the open
source communities. As I said in my earlier mail, this will take time. That
said, I've seen enormous shifts within the ARM partnership already this year
and look forward to more next year.
Merry Christmas / Happy Holidays to one and all.
Dave
ps nice to see that you keep your old email address.Are you still in Wales?
On 23 Dec 2010, at 17:17, Alan Cox wrote:
way to behave. The best way to get companies to change their behaviour is
to find them and support them. Making threatening GPL noises in email does
not help them in any way.
I would disagree based on years of history.
The best way to get a company to change behaviour is for a situation to
occur in which it is in their own hardcore capitalist self interest to
change.
In my experience open source usually mirrors standards in this. The
leading vendors refuse to take part, the smaller vendors see the
opportunity - often working together - and the bigger vendor eithers gets
its backside kicked or does a sharp turn in the right direction.
That's the story of email, of the web, and is occuring currently in
telephony and other areas.
It's also why folks like Dell deserve a lot more credit than they get for
the success of Linux.
If its not commercially sensible it doesn't matter what the licensing
says. They are corporations not charities, if it's not economically
viable for them to manage it all themselves including new driver
releases, legal risk, all their own review and keeping up with DRI then
they have to decide which way to go - some go the hit and run approach
('not got kernel X then sorry but not our problem'), some do the work to
support it release by release but don't go GPL (eg Nvidia), some open up,
others just walk away.
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes
On Thu, Dec 23, 2010 at 1:32 AM, Alex Riesen raa.l...@gmail.com wrote: On Thu, Dec 23, 2010 at 04:54, Linus Torvalds torva...@linux-foundation.org wrote: Why does that code need to figure out some LVDS clock from the BIOS? Why can't the code look at the actual hardware state or similar, since presumably the screen is on after boot. THAT we can rely on, since a BIOS that doesn't initialize LVDS is not going to ever ship even as pre-release. What if the system booted with it's display turned off? Like a closed laptop lid or disconnected monitor? So then we might have to guess and even use the BIOS state for guessing. But what's so hard to understand about that word guess? That really is what happens every single time you use some BIOS table. It's not look up. It's not get the right data. It very much is all about guessing. The BIOS tables are invariably buggy, and have likely only ever been tested with one particular version of Windows. And that's _especially_ true of something like VBIOS tables. They haven't been tested even with windows, they have only been tested with the particular graphics driver that the vendor shipped with that machine. It's quite possible - even likely - that the graphics driver hard-codes something. So think about it - if we boot with the laptop open, you have two choices: ask the hardware for real working state or guess by probing random state from the BIOS that may or may not actually ever be used that way by anything. Which choice would you pick? And if that means that some laptops have to be booted with the lid open, that really isn't a problem. And yes, I do realize that VGA traditionally has had lots of hardware state that is write-only and cannot be read back. It's possible that this case is one of those. I dunno. I hope not. (Side note: resume is different from boot. You should test that resume works with the lid closed, because resume state is not at all guaranteed to be sane at all, lid or no lid. But the way to fix that is NOT to ask the BIOS, it's to remember the state from the original boot from before the suspend). Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32556] screen flickers all the time with desktop image appearing only briefly
https://bugs.freedesktop.org/show_bug.cgi?id=32556 --- Comment #13 from Alex Deucher ag...@yahoo.com 2010-12-23 10:49:28 PST --- How about: pll-flags |= (RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER); Can you also attach a copy of your vbios? (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/pci bus id echo 1 rom cat rom /tmp/vbios.rom echo 0 rom -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32556] screen flickers all the time with desktop image appearing only briefly
https://bugs.freedesktop.org/show_bug.cgi?id=32556 --- Comment #14 from Alex Deucher ag...@yahoo.com 2010-12-23 11:07:39 PST --- Also try: pll-flags |= (RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER | RADEON_PLL_NO_ODD_POST_DIV); -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30131] Command Conquer 3 crashes with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=30131 --- Comment #10 from Martin Stolpe martinsto...@gmail.com 2010-12-23 12:40:36 PST --- (In reply to comment #9) Then you are most probably using direct rendering. Could you possibly obtain a backtrace (i.e. call stack) of the crash? I've tried to switch on wine_d3d, x11drv, x11settings, xrandr, xrender and xvidmode debug channels in wine, but the resulting log file doesn't seem to give any hints about the error (if you're interested I can upload the log file). Are there any other debug settings which I can turn on, which could help you identifying the cause of the crash? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30131] Command Conquer 3 crashes with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=30131 Pavel Ondračka dra...@centrum.cz changed: What|Removed |Added CC||dra...@centrum.cz --- Comment #11 from Pavel Ondračka dra...@centrum.cz 2010-12-23 13:26:15 PST --- Are there any other debug settings which I can turn on, which could help you identifying the cause of the crash? You may find some useful info about obtaining backtraces with Wine here: http://wiki.winehq.org/Backtraces -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32556] screen flickers all the time with desktop image appearing only briefly
https://bugs.freedesktop.org/show_bug.cgi?id=32556 --- Comment #15 from Gildas Le Nadan 3ntr0...@gmail.com 2010-12-23 23:29:12 PST --- Created an attachment (id=41406) -- (https://bugs.freedesktop.org/attachment.cgi?id=41406) vbios.rom Here for Xmas, have a poodle vbios -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32619] [r600g] EE src/gallium/drivers/r600/r600_shader.c/r600_shader_from_tgsi:593 - unsupported token type 3
https://bugs.freedesktop.org/show_bug.cgi?id=32619 Dave Airlie airl...@freedesktop.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Dave Airlie airl...@freedesktop.org 2010-12-23 23:41:54 PST --- should be worked around now: http://cgit.freedesktop.org/mesa/mesa/commit/?id=876effb0e717e8e64050662f6ffa286c22065f5c -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32556] screen flickers all the time with desktop image appearing only briefly
https://bugs.freedesktop.org/show_bug.cgi?id=32556 --- Comment #16 from Gildas Le Nadan 3ntr0...@gmail.com 2010-12-23 23:50:31 PST --- (In reply to comment #13) How about: pll-flags |= (RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER); Can you also attach a copy of your vbios? (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/pci bus id echo 1 rom cat rom /tmp/vbios.rom echo 0 rom With this one screen is completely unusable (similar to the initial situation). Will attach kms_frac_closest.regs -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 32556] screen flickers all the time with desktop image appearing only briefly
https://bugs.freedesktop.org/show_bug.cgi?id=32556 --- Comment #17 from Gildas Le Nadan 3ntr0...@gmail.com 2010-12-23 23:51:50 PST --- Created an attachment (id=41407) -- (https://bugs.freedesktop.org/attachment.cgi?id=41407) registers with KMS patch and RADEON_PLL_USE_FRAC_FB_DIV | RADEON_PLL_PREFER_CLOSEST_HIGHER -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
