fter the original
DISPLAY_FLAGS? DRM_MODE_FLAG_PIXDATA_POSEDGE is easier to get your
head around if you know it is mapped from the DISPLAY_FLAGS_ version.
PDATEN and PPIXDATEDGE don't exactly map to things like EDID field
names either..
> +#define DRM_MODE_FLAG_PPIXDATEDGE (1<<24)
> +#define DRM_MODE_FLAG_NPIXDATEDGE (1<<25)
--
Matt Sealey
On Thu, Oct 10, 2013 at 4:30 AM, Christian König
deathsim...@vodafone.de wrote:
I already suspected that AMD (ATI at that time) had a very good reason to
use this E2PROM to avoid problem with classic DVI monitors (instead of the
wide spread explanation to gain world domination with it).
Whee, I see some crazy paranoia on the news sites, and I figured I'd
chime in having had to deal with weird DVI-HDMI conversion in the
past..
On Tue, Oct 8, 2013 at 3:29 AM, Christian König deathsim...@vodafone.de wrote:
So the poor little one which came with the gfx card should be sufficient,
driver
fundamentally separate.
--
Matt Sealey
Product Development Analyst, Genesi USA, Inc.
and encoder enforcing some kind of order? I actually think DRM is
almost there in this regard, but every DRM driver has too intimate,
driver-level knowledge of what could possibly be connected and I am
trying to avoid that to keep the transmitter and display driver
fundamentally separate.
--
Matt
On Thu, Feb 16, 2012 at 9:51 AM, Adam Jackson wrote:
> On Wed, 2012-02-15 at 22:43 -0600, Matt Sealey wrote:
>> Quick question; if I want to validate a mode given to me by a
>> connector/encoder as workable or not before I am going through the
>> code to actually set that
On Thu, Feb 16, 2012 at 9:51 AM, Adam Jackson a...@redhat.com wrote:
On Wed, 2012-02-15 at 22:43 -0600, Matt Sealey wrote:
Quick question; if I want to validate a mode given to me by a
connector/encoder as workable or not before I am going through the
code to actually set that mode, how would
for the connector/encoder and use the mode_valid I already have to
parse and discard modes which are plainly not
going to be able to be clocked.
--
Matt Sealey
Product Development Analyst, Genesi USA, Inc.
/encoder and use the mode_valid I already have to
parse and discard modes which are plainly not
going to be able to be clocked.
--
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
dri-devel mailing list
dri-devel
Okay I hereby refrain from legal comments.
In any case, this code has passed legal at Freescale and AMD *AND*
Qualcomm. It would not be GPL if it has not been vetted (and it took
them a year to get to this point).
--
Matt Sealey
Product Development Analyst, Genesi USA, Inc.
On Tue, Dec 21
P to the GPU to render it to a texture and came up with an
awful (closed source :) method of ioctls and so on to achieve it. I
had an idea to solve it using DRM and GEM but it's been shot down in
concept now... what's the point? It'll never get into mainline.
--
Matt Sealey
Product Development Analyst, Genesi USA, Inc.
a texture
from the DSP to the GPU to render it to a texture and came up with an
awful (closed source :) method of ioctls and so on to achieve it. I
had an idea to solve it using DRM and GEM but it's been shot down in
concept now... what's the point? It'll never get into mainline.
--
Matt Sealey m
Okay I hereby refrain from legal comments.
In any case, this code has passed legal at Freescale and AMD *AND*
Qualcomm. It would not be GPL if it has not been vetted (and it took
them a year to get to this point).
--
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc
On Mon, Dec 20, 2010 at 11:17 AM, Jerome Glisse wrote:
> On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey wrote:
>> On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann wrote:
>>> On Monday 13 December 2010, Jammy Zhou wrote:
>>>> On Mon, Dec 13, 2010 at 4:45 AM, Linu
enesi has done). It is my
understanding that Freescale/AMD and Qualcomm maintain seperate forks
of the driver and do not cooperate on development, and in any case,
Linaro does not include Qualcomm anyway, therefore it is also to my
understanding that this discussion is also beyond Linaro's remit.
Can't we all just be happy that we actually have 3D drivers?
--
Matt Sealey
Product Development Analyst, Genesi USA, Inc.
On Mon, Dec 20, 2010 at 11:17 AM, Jerome Glisse j.gli...@gmail.com wrote:
On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey m...@genesi-usa.com wrote:
On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann a...@arndb.de wrote:
On Monday 13 December 2010, Jammy Zhou wrote:
On Mon, Dec 13, 2010 at 4:45 AM
Do Freescale still do the printed manuals like I have for the G4?
I'd quite like the MCIMX51RM as a book.. how would I go about getting a copy?
--
Matt Sealey
Product Development Analyst, Genesi USA, Inc.
On Tue, Apr 20, 2010 at 11:41 AM, Jesse Barnes
wrote:
> On Tue, 20 Apr 2010 10:56:41 -0500
Hi Jesse,
> Matt Sealey wrote:
>
>> Is there any canonical or even rough, old documentation (I noticed a
>> connector/encoder structure change lately) on how the DRM
>> crtc/
l and Radeon drivers and working out for
myself why and how they differ in implementation?
BTW the other question is: for future-proofing do I use GEM or TTM or what?
--
Matt Sealey
Product Development Analyst, Genesi USA, Inc.
and working out for
myself why and how they differ in implementation?
BTW the other question is: for future-proofing do I use GEM or TTM or what?
--
Matt Sealey m...@genesi-usa.com
Product Development Analyst, Genesi USA, Inc.
___
dri-devel mailing list
dri
20 matches
Mail list logo
