Hi,
On Tue, Sep 04, 2007 at 10:52:41AM -0700, Jesse Barnes wrote:
> On Sunday, September 2, 2007 6:21 pm [EMAIL PROTECTED] wrote:
> > As for EDID, I totally agree that this can be done in user space
> > just fine. What I'm saying is that no central daemon is required for
> > that. Handling this d
On Sunday, September 2, 2007 6:21 pm [EMAIL PROTECTED] wrote:
> Hi,
>
> On Fri, Aug 24, 2007 at 08:31:10AM -0700, Jesse Barnes wrote:
> > On Thursday, August 23, 2007 6:44:49 pm [EMAIL PROTECTED]
wrote:
> > > I am *not* opposed to a scheme where userspace has to provide
> > > information how to se
Hi,
On Fri, Aug 24, 2007 at 06:08:57AM +0300, Daniel Stone wrote:
> On Fri, Aug 24, 2007 at 03:50:04AM +0200, [EMAIL PROTECTED]
> wrote:
> > Graphics chips are complicated, but the bulk of the complexity is
> > not in modesetting. Do you really think that modesetting (and other
> > graphics hardw
Hi,
On Fri, Aug 24, 2007 at 08:31:10AM -0700, Jesse Barnes wrote:
> On Thursday, August 23, 2007 6:44:49 pm [EMAIL PROTECTED] wrote:
> > I am *not* opposed to a scheme where userspace has to provide
> > information how to set up a desired mode. (Although I'm not conviced
> > it's really necessary
On Aug 23, 07 12:00:39 +0300, Daniel Stone wrote:
> > > If you have ioctl number 32, your next free one is 43, and you want to
> > > change the semantics of UPDATE_WINDOW, then you rename 32 to
> > > UPDATE_WINDOW_OLD, create UPDATE_WINDOW as 43 with the new structure,
> > > and handle both cases.
> At a minimum, there must be a program to determine which outputs have
> monitors
> attached, and what modes are available on those monitors. It's possible this
> could be hardcoded in simple or embedded cases, but for a dynamic system it
> should probably be done in userspace, since EDID ove
On Thursday, August 23, 2007 8:38:46 pm Tiago Vignatti wrote:
> I hope you guys are not forgetting who wants to start two (or more)
> instances of the Xorg server (for multiseat purposes or what ever).
Oh definitely not. This work should make muliseat much easier.
> In this case, the daemon - in
On Thursday, August 23, 2007 6:44:49 pm [EMAIL PROTECTED] wrote:
> I am *not* opposed to a scheme where userspace has to provide
> information how to set up a desired mode. (Although I'm not conviced
> it's really necessary -- both Keith Packard and Dave Airlie argued that
> mode setting is simple
Hi,
[EMAIL PROTECTED] escreveu:
> On Sun, Aug 12, 2007 at 09:36:32PM -0700, Jesse Barnes wrote:
>> On Sunday, August 12, 2007 8:50:12 am [EMAIL PROTECTED] wrote:
>
>>> I fail to understand why you want to put the manager in a daemon,
>>> instead of just letting the kernel do the management, like
On Fri, Aug 24, 2007 at 03:50:04AM +0200, [EMAIL PROTECTED] wrote:
> Graphics chips are complicated, but the bulk of the complexity is not in
> modesetting. Do you really think that modesetting (and other graphics
> hardware management) is more complex than say a wireless network driver?
The API m
Hi,
On Sun, Aug 12, 2007 at 09:36:32PM -0700, Jesse Barnes wrote:
> On Sunday, August 12, 2007 8:50:12 am [EMAIL PROTECTED] wrote:
> > I fail to understand why you want to put the manager in a daemon,
> > instead of just letting the kernel do the management, like it does
> > for all other hardwar
Hi,
On Mon, Aug 20, 2007 at 05:27:43PM +0200, Matthias Hopf wrote:
> On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote:
> > I fail to understand why you want to put the manager in a daemon,
> > instead of just letting the kernel do the management, like it does
> > for all other hardware. Why
On Wed, Aug 22, 2007 at 08:09:18PM +0200, Matthias Hopf wrote:
> On Aug 22, 07 17:21:09 +0300, Daniel Stone wrote:
> > > But that exactly makes version control difficult (lots of cases,
> > > especially if the exact requirements aren't clear from day one).
> >
> > I honestly don't understand the p
On Wed, 2007-08-22 at 20:09 +0200, Matthias Hopf wrote:
> On Aug 22, 07 17:21:09 +0300, Daniel Stone wrote:
>
> > > Without a version field, this is made impossible, something that must be
> > > avoided at all costs.
> >
> > Except that your ioctl then becomes variably-sized unless you add loads
On Aug 22, 07 17:21:09 +0300, Daniel Stone wrote:
> > But that exactly makes version control difficult (lots of cases,
> > especially if the exact requirements aren't clear from day one).
>
> I honestly don't understand the problem. Your ioctl number is _that_
> request. It's not referring to a
On Wednesday, August 22, 2007 6:47:31 am Matthias Hopf wrote:
> On Aug 20, 07 15:45:00 -0700, Keith Packard wrote:
> > On Mon, 2007-08-20 at 17:27 +0200, Matthias Hopf wrote:
> > > Because we won't get an ix86 emulator in kernel space, Linus and others
> > > have been pretty clear about that. Graph
On Wed, Aug 22, 2007 at 03:47:31PM +0200, Matthias Hopf wrote:
> No. But you already limit yourself to the primary card, a new design
> shouldn't be limited that way. And an astonishingly big number of people
> have to rely on vesa fb, because driver development for their hardware
> sucks big time
On Wed, Aug 22, 2007 at 03:42:49PM +0200, Matthias Hopf wrote:
> On Aug 20, 07 19:51:31 +0300, Daniel Stone wrote:
> > On Mon, Aug 20, 2007 at 05:27:43PM +0200, Matthias Hopf wrote:
> > > On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote:
> > > Please be sure that if you design this using ioctl
On Aug 20, 07 15:45:00 -0700, Keith Packard wrote:
> On Mon, 2007-08-20 at 17:27 +0200, Matthias Hopf wrote:
>
> > Because we won't get an ix86 emulator in kernel space, Linus and others
> > have been pretty clear about that. Graphics hardware sometimes needs
> > BIOS calls, on non-i386 hardware t
On Aug 20, 07 19:51:31 +0300, Daniel Stone wrote:
> On Mon, Aug 20, 2007 at 05:27:43PM +0200, Matthias Hopf wrote:
> > On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote:
> > > On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote:
> > > > There should be master (possibly one for each ca
On Mon, 2007-08-20 at 17:27 +0200, Matthias Hopf wrote:
> Because we won't get an ix86 emulator in kernel space, Linus and others
> have been pretty clear about that. Graphics hardware sometimes needs
> BIOS calls, on non-i386 hardware that has to be done by an emulator.
Post-boot, for the primar
On Mon, Aug 20, 2007 at 05:27:43PM +0200, Matthias Hopf wrote:
> On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote:
> > On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote:
> > > There should be master (possibly one for each card) which be the only
> > > one being able to do this call
On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote:
> On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote:
> > There should be master (possibly one for each card) which be the only
> > one being able to do this call:
> > DRM_IOCTL_MODE_SETCRTC - set CRTC parameters
Please be sure that
On Sunday, August 12, 2007 8:50:12 am [EMAIL PROTECTED] wrote:
> Hi,
>
> On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote:
> > There should be master (possibly one for each card) which be the only
> > one being able to do this call:
> > DRM_IOCTL_MODE_SETCRTC - set CRTC parameters
>
>
Hi,
On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote:
> There should be master (possibly one for each card) which be the only
> one being able to do this call:
> DRM_IOCTL_MODE_SETCRTC - set CRTC parameters
[...]
> master (big boss)
> - X server (got its framebuffer)
> - X app
Jakob Bornecrantz wrote:
>> There should be master (possibly one for each card) which be the only
>> one being able to do this call:
>> DRM_IOCTL_MODE_SETCRTC - set CRTC parameters
>> (which i assume is set the mode, associat crtc-output and set framebuffer)
>>
>> Other call can be made by any othe
> I don't agree with everything but the general idea is a good one.
>
> > There should be master (possibly one for each card) which be the only
> > one being able to do this call:
> > DRM_IOCTL_MODE_SETCRTC - set CRTC parameters
> > (which i assume is set the mode, associat crtc-output and set fram
> Well ain't I'm rude not signing off :)
>
> Cheers Jakob "Wlallbraker" Bornecrekrantz.
I just about can't do anything right to day :)
Cheers Jakob.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log
On 02/08/07, Jerome Glisse <[EMAIL PROTECTED]> wrote:
> Jesse Barnes wrote:
> > I finally found some time to create a new wiki page for all the
> > modesetting/configuration related DRM enhancements we've been talking about:
> > http://dri.freedesktop.org/wiki/DrmModesetting
> >
> > Please take a l
Jesse Barnes wrote:
> I finally found some time to create a new wiki page for all the
> modesetting/configuration related DRM enhancements we've been talking about:
> http://dri.freedesktop.org/wiki/DrmModesetting
>
> Please take a look and let me know what you think. I still have to go
> throug
Michel Dänzer wrote:
> On Thu, 2007-08-02 at 17:44 +0200, Jerome Glisse wrote:
>> Btw i think that some GPU can wait on vblank using cmd ie you
>> don't need to ask the card to emit irq you just insert a cmd in
>> stream which stall further cmd execution until vblank happen,
>> this might be good f
On Thu, 2007-08-02 at 17:44 +0200, Jerome Glisse wrote:
>
> Btw i think that some GPU can wait on vblank using cmd ie you
> don't need to ask the card to emit irq you just insert a cmd in
> stream which stall further cmd execution until vblank happen,
> this might be good for power consumption.
Jesse Barnes wrote:
> I finally found some time to create a new wiki page for all the
> modesetting/configuration related DRM enhancements we've been talking about:
> http://dri.freedesktop.org/wiki/DrmModesetting
>
> Please take a look and let me know what you think. I still have to go
> throug
33 matches
Mail list logo
