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
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 t
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.cg
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 im
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
> 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 care
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 str
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
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
> 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 situati
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 (
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.
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/bu
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://bug
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_d3
https://bugs.freedesktop.org/show_bug.cgi?id=30131
Pavel Ondračka changed:
What|Removed |Added
CC||dra...@centrum.cz
--- Comment #11 from
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)
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 bugmai
https://bugs.freedesktop.org/show_bug.cgi?id=32619
Dave Airlie changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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 yo
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_PL
>
> 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
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
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
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
>>>
>>>
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 the
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
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 t
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.c
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 im
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
> 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 care
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 str
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
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
> 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 situati
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 (
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.
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/b
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://bu
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_d3
https://bugs.freedesktop.org/show_bug.cgi?id=30131
Pavel Ondra?ka changed:
What|Removed |Added
CC||drakkk at centrum.cz
--- Comment #11 fr
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)
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 bug
https://bugs.freedesktop.org/show_bug.cgi?id=32619
Dave Airlie changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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
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
47 matches
Mail list logo
