[PATCH] drm: exynos: Fix fb_videomode <-> drm_mode_modeinfo conversion

change my mind. What do you do, sir? ~ Keynes Corbin Simpson

Re: [PATCH] drm: exynos: Fix fb_videomode <-> drm_mode_modeinfo conversion

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

Re: [PATCH] agp: Enable all supported rates for graphic cards

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? >

[PATCH] agp: Enable all supported rates for graphic cards

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? >

Re: [PATCH] agp: Enable all supported rates for graphic cards

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

[PATCH] agp: Enable all supported rates for graphic cards

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

Re: [PATCH] agp: Fix multi-line warning message whitespace

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,

[PATCH] agp: Fix multi-line warning message whitespace

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,

Re: Proposal for a low-level Linux display framework

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

Proposal for a low-level Linux display framework

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

Re: Proposal for a low-level Linux display framework

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

Re: Proposal for a low-level Linux display framework

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

Proposal for a low-level Linux display framework

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

Proposal for a low-level Linux display framework

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

Re: [git pull] drm fixes

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

[git pull] drm fixes

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

Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.

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 &

[RFC PATCH] HDMI:Support for EDID parsing in kernel.

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

Re: Future desktop on dumb frame buffers?

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

Future desktop on dumb frame buffers?

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

Re: [PATCH 1/2] fbdev: sh_mobile_lcdc: Add YUV input support

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

[PATCH 1/2] fbdev: sh_mobile_lcdc: Add YUV input support

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

Re: [PATCH] drm: do not leak kernel addresses via /proc/dri/*/vma

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

[PATCH] drm: do not leak kernel addresses via /proc/dri/*/vma

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

Re: [PATCH] drm/radeon/kms: fix pll algo quirk function

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, &

[PATCH] drm/radeon/kms: fix pll algo quirk function

_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

Re: [PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform

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

[PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform

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

Re: Radeon support state in libkms

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

Radeon support state in libkms

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

Re: [PATCH] drm: dumb scanout create/mmap for intel/radeon (v3)

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

[PATCH] drm: dumb scanout create/mmap for intel/radeon (v3)

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

Re: glint KMS - how to proceed?

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

glint KMS - how to proceed?

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

Re: Closed source userspace graphics drivers with an open source kernel component

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

Closed source userspace graphics drivers with an open source kernel component

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

Re: [RFC] Qualcomm 2D/3D graphics driver

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

[RFC] Qualcomm 2D/3D graphics driver

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

Re: EDID checksum errors

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

EDID checksum errors

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

Re: [PATCH] drm/radeon/kms: fix typo in evergreen_gpu_init

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

[PATCH] drm/radeon/kms: fix typo in evergreen_gpu_init

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

Re: [PATCH] drm/radeon/r200: fix typo in packet checker for tracking textures

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); > -- >

[PATCH] drm/radeon/r200: fix typo in packet checker for tracking textures

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); > -- >

Re: [PATCH 2/20] drivers/gpu/drm: Use kzalloc

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

[PATCH 2/20] drivers/gpu/drm: Use kzalloc

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

[PATCH] drivers/gpu/radeon: Add MSPOS regs to safe list.

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

[PATCH] drivers/gpu/radeon: Add MSPOS regs to safe list.

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

Re: [PATCH 0/2] drm/radeon/kms: tex3D mipmap fix & R500 VAP regs

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

[PATCH 0/2] drm/radeon/kms: tex3D mipmap fix & R500 VAP regs

When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson