change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
mostawesomed...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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?
>
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
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,
FWIW, Reviewed-by: Corbin Simpson mostawesomed...@gmail.com
Sending from a mobile, pardon my terseness. ~ C.
On Nov 6, 2011 7:04 AM, Tormod Volden lists.tor...@gmail.com wrote:
From: Tormod Volden debian.tor...@gmail.com
Signed-off-by: Tormod Volden debian.tor...@gmail.com
---
drivers/char
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 lists.tor...@gmail.com wrote:
From: Tormod Volden
Thanks for writing it!
Reviewed-by: Corbin Simpson mostawesomed...@gmail.com
Sending from a mobile, pardon my terseness. ~ C.
On Nov 6, 2011 10:39 AM, Tormod Volden lists.tor...@gmail.com wrote:
On Sun, Nov 6, 2011 at 4:37 PM, Corbin Simpson
mostawesomed...@gmail.com wrote:
Trusting
ely, 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
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
mostawesomed...@gmail.com
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
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
>>>
Sending from a mobile, pardon my terseness. ~ C.
On Sep 15, 2011 1:05 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Thu, Sep 15, 2011 at 19:52, Alex Deucher alexdeuc...@gmail.com
wrote:
While the DRM has
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 alexdeuc...@gmail.com wrote:
On Thu, Sep 15, 2011 at 1:56 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Thu, Sep 15, 2011 at 19:52, Alex Deucher
ija 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
>> 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
, 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
mostawesomed...@gmail.com
to improve this.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
mostawesomed...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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
the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
mostawesomed...@gmail.com
___
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
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
? ? ? ? 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
_clock,
> _div, _fb_div,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? _div, _div);
> - ? ? ? else
> - ? ? ? ? ? ? ? radeon_compute_pll_legacy(pll, adjusted_clock, _clock,
> _div, _fb_div,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? _div, _div);
> + ? ? ? ? ? ? ? break;
> + ? ? ? };
>
> ? ? ? ?atombios_crtc_program_ss(crtc, ATOM_DISABLE, radeon_crtc->pll_id, );
>
> --
> 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
; 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
at 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
is that, anyway?
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
mostawesomed...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
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
onversation 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
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
mostawesomed...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
m, 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
, 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
mostawesomed...@gmail.com
___
dri-devel mailing list
dri
___
> 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
ything 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
@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
mostawesomed...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
ly 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
, 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
mostawesomed...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
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
*/
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
mostawesomed...@gmail.com
___
dri-devel mailing
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);
> --
> @@ -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 (dev_priv =
));
dev-dev_private = (void *)dev_priv;
dev_priv-chipset = (enum savage_family)chipset;
Zero idea if anybody cares about savage DRM, but this looks like a
completely reasonable patch.
Reviewed-by: Corbin Simpson mostawesomed...@gmail.com
~ C.
--
When the facts change, I change my mind
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
facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
44 matches
Mail list logo
