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 |
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
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 #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
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
> 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
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)
> 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
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
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
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
>>>
https://bugs.freedesktop.org/show_bug.cgi?id=30131
Pavel Ondra?ka changed:
What|Removed |Added
CC||drakkk at centrum.cz
--- Comment #11
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
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/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
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
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
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
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
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
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
>
> 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
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/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
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
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
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
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:
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
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
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
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
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
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 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
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=30131
Pavel Ondračka dra...@centrum.cz changed:
What|Removed |Added
CC||dra...@centrum.cz
---
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/show_bug.cgi?id=32619
Dave Airlie airl...@freedesktop.org changed:
What|Removed |Added
Status|NEW |RESOLVED
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
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 |
43 matches
Mail list logo
