On Tue, Mar 04, 2003 at 11:10:02PM -0800, Ian Romanick wrote:
Jens Owen wrote:
Concern #3: Readability by the active contributors. I'm not the only
old fuddy duddy in this group of developers. How much readability
time do you figure the young C++ whipper snappers will save by
On Wed, Mar 05, 2003 at 12:30:50AM -0800, Philip Brown wrote:
Are you saying that C++ somehow allows for more code sharing between
drivers than straight ANSI C?
If you think that the used computer language is so irrelevant, then why
is there such a great number of them? Or are you saying that C
On Tue, Mar 04, 2003 at 11:10:02PM -0800, Ian Romanick wrote:
Jens Owen wrote:
Concern #1: Acceptance into XFree86, etc. Creating dependencies on
C++ compilers could be a big issue for some of the major projects that
utilize our code.
This is probably the biggest issue. I think if
Hi Andreas,
On Wed, Mar 05, 2003 at 01:25:02AM +0100, Andreas Karrenbauer wrote:
Hello,
I've attached some patches for the Savage ddx and the drm. The drm
supports two basic ioctls right now. The output in the XFree86.0.log
gives me now
[...]
But that doesn't mean that we have
Title: ::M::Imbewofonvhisimrbkitaqjgnmpsvlwxwljubsgrrdktepnbgrfuhrpx
ANNA
5Mq448S88kh4y6E
5852bMrb9-521vMEe7822MxMO8-695SweB7291whic0-653RPda7398UWSK1-512l60N¬HYÞµéX¬²'²Þu¼¶{¬© ®Ê NZXÁ8^uæî«~Ü¢je{(uàÞnè xü/¾¦º ©¬q©åy«ÞÊyéb h²Ö§uج¢¸×NZXÁƧ
On Tue, 2003-03-04 at 11:36, Michel Dänzer wrote:
I have not provided a diff because it is quite a hack and very
system
specific, at the moment. Effectively, I forced the virtual size to
be
2048x768, hacked the RADEONDoAdjustFrame() function to fix views as
I
wanted them, used the
On Wed, Mar 05, 2003 at 11:06:45AM -0500, Jonathan Thambidurai wrote:
On Tue, 2003-03-04 at 11:36, Michel Dänzer wrote:
I have not provided a diff because it is quite a hack and very
system
specific, at the moment. Effectively, I forced the virtual size to
be
2048x768, hacked the
On Wednesday 05 March 2003 12:10 am, Ian Romanick wrote:
Jens Owen wrote:
Jose,
I've been on the road for the last few days, so I haven't had a chance
to express my concern for porting the DRI to C++. Please take these
concerns with a grain of salt as I am definitely in the old
On Wed, 5 Mar 2003, Nicholas Leippe wrote:
I agree with Jose--let the features used be chosen on technical merit, not
just somebody's whim. Imo, it is far too premature to just discard this or
that feature of C++.
If people decide to go with C++ (which I don't disagree with per se),
On Wed, 5 Mar 2003 10:24:12 -0700
Nicholas Leippe [EMAIL PROTECTED] wrote:
On Wednesday 05 March 2003 12:10 am, Ian Romanick wrote:
Jens Owen wrote:
Jose,
I've been on the road for the last few days, so I haven't had a chance
to express my concern for porting the DRI to C++.
On Wednesday 05 March 2003 10:31 am, Linus Torvalds wrote:
Also note that if you don't allow exceptions (which I would _strongly_
encourage), you can't really use new - unless you think it's ok to
SIGSEGV under low-mem circumstances. Which it might be, of course, in some
situations.
I may
Philip Brown wrote:
On Tue, Mar 04, 2003 at 11:10:02PM -0800, Ian Romanick wrote:
Jens Owen wrote:
Concern #3: Readability by the active contributors. I'm not the only
old fuddy duddy in this group of developers. How much readability
time do you figure the young C++ whipper snappers will
José Fonseca wrote:
On Tue, Mar 04, 2003 at 11:10:02PM -0800, Ian Romanick wrote:
Jens Owen wrote:
Concern #1: Acceptance into XFree86, etc. Creating dependencies on
C++ compilers could be a big issue for some of the major projects that
utilize our code.
This is probably the biggest issue.
On Wed, Mar 05, 2003 at 10:04:40AM -0800, Ian Romanick wrote:
Philip Brown wrote:
Are you saying that C++ somehow allows for more code sharing between
drivers than straight ANSI C?
It's not so much that it allows it as it makes it less painful. Look at
the texmem-0-0-1 branch. In
Leif Delgass wrote:
Now that XFree86 4.3.0 is tagged/released, is there a plan for merging
4.3.0 into the DRI trunk?
I sure hope so! There are a couple branches that would like to merge
into the trunk soon, but want to wait until after the 4.3.0 merge. I
know that in the past David Dawes has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Wednesday 05 March 2003 17:31, Linus Torvalds wrote:
Also note that if you don't allow exceptions (which I would _strongly_
encourage), you can't really use new - unless you think it's ok to
SIGSEGV under low-mem circumstances. Which it
On Wednesday 05 March 2003 10:54 am, Felix Kühling wrote:
If you use the standard library you have to start worrying about ABI
compatibility issues. How much trouble is it to write C++ code that can
be linked without the standard library. I mean avoiding things like
std::cout is no problem.
On Wed, Mar 05, 2003 at 09:31:09AM -0800, Linus Torvalds wrote:
On Wed, 5 Mar 2003, Nicholas Leippe wrote:
I agree with Jose--let the features used be chosen on technical
merit, not just somebody's whim. Imo, it is far too premature to
just discard this or that feature of C++.
If
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On Wednesday 05 March 2003 18:24, Ian Romanick wrote:
Right. Part of the technical basis that we have to consider is
compiler and operating system support. Linux/x86 may be the main system
that we consider, but it is by no means the only
On Wed, Mar 05, 2003 at 06:54:31PM +0100, Felix Kühling wrote:
On Wed, 5 Mar 2003 10:24:12 -0700 Nicholas Leippe [EMAIL PROTECTED]
wrote:
Templates provide a great deal of power that you may not want to do
without. For instance, you could use portions of the STL (always
good to use the
On Wed, 5 Mar 2003 11:54:56 -0700
Nicholas Leippe [EMAIL PROTECTED] wrote:
On Wednesday 05 March 2003 10:54 am, Felix Kühling wrote:
If you use the standard library you have to start worrying about ABI
compatibility issues. How much trouble is it to write C++ code that can
be linked
On Wed, 5 Mar 2003 19:22:39 +
José Fonseca [EMAIL PROTECTED] wrote:
On Wed, Mar 05, 2003 at 06:54:31PM +0100, Felix Kühling wrote:
[snip]
But does C++ use the library behind your back?
AFAIK g++ alway implicitly links with libstdc++.
I don't believe there is any dependency of STL on
On Wed, Mar 05, 2003 at 10:24:12AM -0800, Ian Romanick wrote:
José Fonseca wrote:
On Tue, Mar 04, 2003 at 11:10:02PM -0800, Ian Romanick wrote:
Jens Owen wrote:
Concern #1: Acceptance into XFree86, etc. Creating dependencies on
C++ compilers could be a big issue for some of the major
On Wed, 5 Mar 2003, [iso-8859-15] José Fonseca wrote:
Actually virtual code will be used extensively, especially in the Mesa
wrapper classes, but there is no other way around it - the current Mesa
C driver callback table has more than 112 functions.
Oh, I agree that you should not avoid
José Fonseca wrote:
First thing is to remove references to the ring* variables in DRM and
DDX!
I've done this now. The diff is attached.
After that we need to define the macros for MMIO in DRM and write some
utility functions for stuff like wait for card is idle. Both these
things can be based
VP-RX Penis Enlargement Pills
Click Here
Finally!! A medical breakthrough in science has enabled a team of doctors and sex experts to create a pill that is designed to enlarge the male penis by length and width.
Our tests show that out of 1,500 test subjects, the average gain after 4
On Wednesday 05 March 2003 12:28 pm, Felix Kühling wrote:
[snip]
The developer may as well implement his own container types as
templates. My point is that STL seems quite bloated and often a bit
clumsy to use. The code I wrote using STL was never exactly well
readable (maybe my own fault). It
Philip Brown wrote:
On Wed, Mar 05, 2003 at 10:04:40AM -0800, Ian Romanick wrote:
Also, rather than containing the struct, you could do what is done already
in the drm level, with drm_map_t vs drm_local_map_t (and all over the X
server code), and just extend the struct, rather than encapsulating
Andreas,
Do you have an SourceForge user account? I want to give CVS write
access.
On Wed, Mar 05, 2003 at 08:57:28PM +0100, Andreas Karrenbauer wrote:
José Fonseca wrote:
First thing is to remove references to the ring* variables in DRM and
DDX!
I've done this now. The diff is
Brian,
I scratched an itch and made this dynamic. You can see it at:
http://lfm.sourceforge.net/dritest/dri_driver_features.phtml
and of course grab it if you want from:
/home/groups/l/lf/lfm/htdocs/dritest/dri_driver_features.phtml
I was thinking it would be nice to color code it even more
On Wed, Mar 05, 2003 at 01:08:52PM -0800, Ian Romanick wrote:
Philip Brown wrote:
Also, rather than containing the struct, you could do what is done already
in the drm level, with drm_map_t vs drm_local_map_t (and all over the X
server code), and just extend the struct, rather than
Philip Brown wrote:
On Wed, Mar 05, 2003 at 01:08:52PM -0800, Ian Romanick wrote:
Philip Brown wrote:
Also, rather than containing the struct, you could do what is done already
in the drm level, with drm_map_t vs drm_local_map_t (and all over the X
server code), and just extend the struct,
Andreas Karrenbauer wrote:
José Fonseca wrote:
Andreas,
Do you have an SourceForge user account? I want to give CVS write
access.
Well, I just created one. My login is karrenbauer. I'm used to CVS but
not for such huge projects with different branches. Thus, I have to read
the policies and
Hello,
attached is an updated dri configuration design. Most of the changes are
based on the feedback on the list and some things that became clearer
after reading the XML 1.0 recommendation. There are still enough of open
issues, so don't hesitate to comment on these. The most important one
that
Nicholas Leippe wrote:
Brian,
I scratched an itch and made this dynamic. You can see it at:
http://lfm.sourceforge.net/dritest/dri_driver_features.phtml
and of course grab it if you want from:
/home/groups/l/lf/lfm/htdocs/dritest/dri_driver_features.phtml
Neat - I like it.
I was thinking it
On Wed, Mar 05, 2003 at 11:16:18PM +0100, Andreas Karrenbauer wrote:
José Fonseca wrote:
Andreas,
Do you have an SourceForge user account? I want to give CVS write
access.
Well, I just created one. My login is karrenbauer. I'm used to CVS but
not for such huge projects with different
On Wed, Mar 05, 2003 at 02:36:21PM -0800, Ian Romanick wrote:
I suppose that it is doable, but it just seems wrong. Doesn't this just
boil down to inheritance by conincidence? Expecting each driver to
duplicate the same data structures and add their unique data onto the
end, without any
In short, I don't see why everyone is so keen to accept C++ but only if it is
somehow hobbled from the onset? C++ is a tool. Tools work best when the
right one is chosen for the job, the tip is sharp, and the handle is not
splintered or cut off. If the problem does not map into something
On Saturday 01 March 2003 07:19 pm, Alan Cox wrote:
Old SiS - public
Trident - public
Drivers - none.
Old SiS - Utah-GLX. They had an alpha of a driver for that chipset (I
happened to have one, but not the time to pursue improving upon it at the
time...).
As for me and helping out,
I would simply like to know if the Radeon hardware supports 24 bpp
hardware acceleration and I might be able to code it. Thanks for any
response.
--Jonathan Thambidurai
---
This SF.net email is sponsored by: Etnus, makers of
Allen Akin wrote:
Microsoft bears a lot of
the burden for D3D by collecting and maintaining the common code (as
well as nontechnical stuff like patent licensing and sublicensing). SGI
didn't do that for OpenGL in the early days, and by the time it
understood the problem, most hardware vendors had
Linus Torvalds wrote:
On Sun, 2 Mar 2003, Linus Torvalds wrote:
The _second_ DRI-enabled X startup caused problems, even if I had done
multiple non-DRI X sessions in between. This is what makes me think that
the DRI kernel modules keep some history around that they shouldn't. And
maybe the
On 06 Mar 2003 01:05:05 +
Alan Cox [EMAIL PROTECTED] wrote:
I'd argue strongly in favour of the former or a C with structs for the
virtual operation sets for performance reasons, and because its easier
for embedded devices than hauling in the entire C++ and STL class
libraries. Its much
Hi, Jens!
On Wed, Mar 05, 2003 at 09:52:58PM -0700, Jens Owen wrote:
| Allen Akin wrote:
| Microsoft bears a lot of
| the burden for D3D by collecting and maintaining the common code (as
| well as nontechnical stuff like patent licensing and sublicensing). SGI
| didn't do that for OpenGL in the
44 matches
Mail list logo
