When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Permits MSAA and D3D-style rasterization.
Signed-off-by: Corbin Simpson
---
drivers/gpu/drm/radeon/reg_srcs/r300 |2 ++
drivers/gpu/drm/radeon/reg_srcs/r420 |2 ++
drivers/gpu/drm/radeon/reg_srcs/rv515 |2 ++
3 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers
FWIW, Reviewed-by: Corbin Simpson
Sending from a mobile, pardon my terseness. ~ C.
On Nov 6, 2011 7:04 AM, "Tormod Volden" wrote:
> From: Tormod Volden
>
> Signed-off-by: Tormod Volden
> ---
> drivers/char/agp/generic.c |8
> 1 files changed,
Trusting the spec worries me; could this break anybody?
Is there any reason to use the not-so-magic numbers instead of the named
constants?
Sending from a mobile, pardon my terseness. ~ C.
On Nov 6, 2011 7:03 AM, "Tormod Volden" wrote:
> From: Tormod Volden
>
> Some cards report that they supp
Thanks for writing it!
Reviewed-by: Corbin Simpson
Sending from a mobile, pardon my terseness. ~ C.
On Nov 6, 2011 10:39 AM, "Tormod Volden" wrote:
> On Sun, Nov 6, 2011 at 4:37 PM, Corbin Simpson
> wrote:
> > Trusting the spec worries me; could this break anybody?
>
e my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Sending from a mobile, pardon my terseness. ~ C.
On Sep 15, 2011 1:05 PM, "Alex Deucher" wrote:
> On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
> wrote:
>> On Thu, Sep 15, 2011 at 19:52, Alex Deucher
wrote:
>>> While the DRM has historically targeted 3D acceleration, that is not a
>>> requ
Wasn't there a driver for qemu cirrus "hardware"?
Sending from a mobile, pardon my terseness. ~ C.
On Sep 15, 2011 1:05 PM, "Alex Deucher" wrote:
> On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
> wrote:
>> On Thu, Sep 15, 2011 at 19:52, Alex Deucher
wrote:
>>> While the DRM has historical
t just so happens,
fortunately, that the only things which differ from card to card and
cannot be abstracted from kernel to userspace are accelerated
rendering commands.
You're conflating DRM and KMS. It's possible to provide KMS without
DRM: Modesetting withou
ation on v2 was
about cursors -- were they going to be handled through this patch?
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
ts.
That said, yeah, the libkms maintainer probably should pull that code
in. Who is that, anyway?
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
ount of work. I
> haven't seen anything in these SoC platforms that makes them so
> radically different that they need their own API. If there are any,
> we'd love to hear about them so they can be addressed.
>
> Alex
>
>> So, no, there are no plans to share an
l_avivo(pll, adjusted_clock, &pll_clock,
> &fb_div, &frac_fb_div,
> &ref_div, &post_div);
> - else
> - radeon_compute_pll_legacy(pll, adjusted_clock, &pll_clock,
> &fb_div, &frac_fb_div,
&
M_WRITE ? 'w' : '-',
> vma->vm_flags & VM_EXEC ? 'x' : '-',
> --
> 1.7.2.3
This is a highly reasonable patch. Does 0x%pK show up as 0x0x0 in the
log, or just 0x0? Other than that...
Reviewed-by: Corbin Simpson
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
I am slightly curious about this as well; I have a device with only YUV
scanout and was considering KMS, but don't know what the best approach is.
At least one KMS driver, nouveau, has to wrap all accesses to its scanout
buffers on certain chipsets for tiling reasons, so the same strategy might
wo
of the big goals of KMS was a generic
userspace-facing API, like FB, but without the suck.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
nteroperability.
>
>> Do you really think the differences between your code and the existing
>> DRM code are irreconcilable?
>>
> On the contrary if there is a library-ized EDID parsing using the
> drm_edid, and there is any delta / fields( Parsing the video block in
&
or Ilija to see and address
Michel's complaints. It's not too late to improve this.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
ge_bci.c
> @@ -539,11 +539,10 @@ int savage_driver_load(struct drm_device
> {
> drm_savage_private_t *dev_priv;
>
> - dev_priv = kmalloc(sizeof(drm_savage_private_t), GFP_KERNEL);
> + dev_priv = kzalloc(sizeof(drm_savage_private_t), GFP_KERNEL);
> if (de
R100_TRACK_COMP_DXT1;
> + track->textures[i].compress_format =
> R100_TRACK_COMP_DXT35;
> break;
> }
> track->textures[i].cube_info[4].width = 1 << ((idx_value >>
> 16) & 0xf);
> --
>
to avoid, say:
int threads = rdev->config.evergreen.max_threads - ps_thread_count;
threads /= 6; /* Divide by six for some reason */
threads &= ~7; /* Round down to the next multiple of eight for some
other reason */
Admittedly, I don't know the code at all, but this just feels lik
bly use monitors with
EDIDs that have bad checksums, in case the checksum is the only bad
part of an otherwise valid EDID.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
dri-devel mailing list
dri-devel@li
to rename everything to
> something a little bit more descriptive and a little bit less cryptic.
Fascinating and fantastic.
We really ought to ack those DRM platform_device patches.
Where's the modesetting done?
Is the userspace code available? Upstream isn't interested in code
that can't be tested, and part of that is making userspace code open
and available.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
rdware vendors themselves.
>
> --
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
C
ht. I am, if nothing else, a lover of DDXs. tdfx needs it
anyway -- DRI1 is kind of painful with the current setup.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
___
dri-devel mailing list
dri-deve
Sending from a mobile, pardon my terseness. ~ C.
On Sep 15, 2011 1:05 PM, "Alex Deucher" wrote:
> On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
> wrote:
>> On Thu, Sep 15, 2011 at 19:52, Alex Deucher
wrote:
>>> While the DRM has historically targeted 3D acceleration, that is not a
>>> requ
Wasn't there a driver for qemu cirrus "hardware"?
Sending from a mobile, pardon my terseness. ~ C.
On Sep 15, 2011 1:05 PM, "Alex Deucher" wrote:
> On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
> wrote:
>> On Thu, Sep 15, 2011 at 19:52, Alex Deucher
wrote:
>>> While the DRM has historical
t just so happens,
fortunately, that the only things which differ from card to card and
cannot be abstracted from kernel to userspace are accelerated
rendering commands.
You're conflating DRM and KMS. It's possible to provide KMS without
DRM: Modesetting without acceleration.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
ts.
That said, yeah, the libkms maintainer probably should pull that code
in. Who is that, anyway?
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
ount of work. ?I
> haven't seen anything in these SoC platforms that makes them so
> radically different that they need their own API. ?If there are any,
> we'd love to hear about them so they can be addressed.
>
> Alex
>
>> So, no, there are no plans to share anything between the two (except perhaps
>> EDID and CEC parsing should that become relevant).
>>
>> Oh, and let me join Andy in saying that the drm/kms/whatever API
>> documentation
>> *really* needs a lot of work.
I know this is sort of a "me too" as none of my code's upstream yet,
but the barrier posed by the lack of documentation for KMS is
*massive* since the only KMS drivers are for highly complex pieces of
hardware, making them difficult to read. The entire KMS API can be
implemented in a single C file for simple hardware, just like the FB
API, but you'd never know it by looking at the existing drivers.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
_PLL_ALGO_AVIVO:
> ? ? ? ? ? ? ? ?radeon_compute_pll_avivo(pll, adjusted_clock, &pll_clock,
> &fb_div, &frac_fb_div,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? &ref_div, &post_div);
> - ? ? ? else
> - ? ? ? ? ? ? ? radeon_compute_pll_legacy(pll, adjusted_clock, &pll_clock,
> &fb_div, &frac_fb_div,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? &ref_div, &post_div);
> + ? ? ? ? ? ? ? break;
> + ? ? ? };
>
> ? ? ? ?atombios_crtc_program_ss(crtc, ATOM_DISABLE, radeon_crtc->pll_id, &ss);
>
> --
> 1.7.1.1
I can get behind this.
Reviewed-by: Corbin Simpson
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
ne of the big goals of KMS was a generic
userspace-facing API, like FB, but without the suck.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
nteroperability.
>
>> Do you really think the differences between your code and the existing
>> DRM code are irreconcilable?
>>
> On the contrary if there is a library-ized ?EDID parsing using the
> drm_edid, and there is any delta / fields( Parsing the video block in
> CEA extension for Short Video Descriptor, Vendor block for AV delay
> /Deep color information etc) that are parsed with the RFC i posted i
> would be happy to add.
Something just occurred to me. Why do video input drivers need EDID?
Perhaps I'm betraying my youth here, but none of my TV tuners have the
ability to read EDIDs in from the other side of the coax/RCA jack, and
IIUC they really only care about whether they're receiving NTSC or
PAL. The only drivers that should be parsing EDIDs are FB and KMS
drivers, right?
So why should this be a common library? Most kernel code doesn't need
it. Or is there a serious need for video input to parse EDIDs?
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
or Ilija to see and address
Michel's complaints. It's not too late to improve this.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
FWIW, Reviewed-by: Corbin Simpson
Sending from a mobile, pardon my terseness. ~ C.
On Nov 6, 2011 7:04 AM, "Tormod Volden" wrote:
> From: Tormod Volden
>
> Signed-off-by: Tormod Volden
> ---
> drivers/char/agp/generic.c |8
> 1 files changed,
Trusting the spec worries me; could this break anybody?
Is there any reason to use the not-so-magic numbers instead of the named
constants?
Sending from a mobile, pardon my terseness. ~ C.
On Nov 6, 2011 7:03 AM, "Tormod Volden" wrote:
> From: Tormod Volden
>
> Some cards report that they supp
Thanks for writing it!
Reviewed-by: Corbin Simpson
Sending from a mobile, pardon my terseness. ~ C.
On Nov 6, 2011 10:39 AM, "Tormod Volden" wrote:
> On Sun, Nov 6, 2011 at 4:37 PM, Corbin Simpson
> wrote:
> > Trusting the spec worries me; could this break anybody?
>
to rename everything to
> something a little bit more descriptive and a little bit less cryptic.
Fascinating and fantastic.
We really ought to ack those DRM platform_device patches.
Where's the modesetting done?
Is the userspace code available? Upstream isn't interested in code
that can't be tested, and part of that is making userspace code open
and available.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
are vendors themselves.
>
> --
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
ht. I am, if nothing else, a lover of DDXs. tdfx needs it
anyway -- DRI1 is kind of painful with the current setup.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
R100_TRACK_COMP_DXT1;
> + ? ? ? ? ? ? ? ? ? ? ? track->textures[i].compress_format =
> R100_TRACK_COMP_DXT35;
> ? ? ? ? ? ? ? ? ? ? ? ?break;
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?track->textures[i].cube_info[4].width = 1 << ((idx_value >>
> 16) & 0xf);
> --
>
to avoid, say:
int threads = rdev->config.evergreen.max_threads - ps_thread_count;
threads /= 6; /* Divide by six for some reason */
threads &= ~7; /* Round down to the next multiple of eight for some
other reason */
Admittedly, I don't know the code at all, but this just feels like a
breeding ground for typos and eyestrain.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
bly use monitors with
EDIDs that have bad checksums, in case the checksum is the only bad
part of an otherwise valid EDID.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
ge_bci.c
> @@ -539,11 +539,10 @@ int savage_driver_load(struct drm_device
> ?{
> ? ? ? ?drm_savage_private_t *dev_priv;
>
> - ? ? ? dev_priv = kmalloc(sizeof(drm_savage_private_t), GFP_KERNEL);
> + ? ? ? dev_priv = kzalloc(sizeof(drm_savage_private_t), GFP_KERNEL);
> ? ? ? ?if (de
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
Permits MSAA and D3D-style rasterization.
Signed-off-by: Corbin Simpson
---
drivers/gpu/drm/radeon/reg_srcs/r300 |2 ++
drivers/gpu/drm/radeon/reg_srcs/r420 |2 ++
drivers/gpu/drm/radeon/reg_srcs/rv515 |2 ++
3 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers
M_WRITE ? 'w' : '-',
> ? ? ? ? ? ? ? ? ? ? ? ? ? vma->vm_flags & VM_EXEC ? 'x' : '-',
> --
> 1.7.2.3
This is a highly reasonable patch. Does 0x%pK show up as 0x0x0 in the
log, or just 0x0? Other than that...
Reviewed-by: Corbin Simpson
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
ation on v2 was
about cursors -- were they going to be handled through this patch?
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
I am slightly curious about this as well; I have a device with only YUV
scanout and was considering KMS, but don't know what the best approach is.
At least one KMS driver, nouveau, has to wrap all accesses to its scanout
buffers on certain chipsets for tiling reasons, so the same strategy might
wo
change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
50 matches
Mail list logo
