Menu
▾
▴
chromium-dev — For developers of the Chromium framework or SPU's
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
(10) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(34) |
Aug
(59) |
Sep
(16) |
Oct
(11) |
Nov
(83) |
Dec
(52) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(40) |
Feb
(82) |
Mar
(190) |
Apr
(72) |
May
(95) |
Jun
(128) |
Jul
(195) |
Aug
(267) |
Sep
(202) |
Oct
(88) |
Nov
(60) |
Dec
(34) |
| 2003 |
Jan
(81) |
Feb
(73) |
Mar
(74) |
Apr
(53) |
May
(15) |
Jun
(61) |
Jul
(32) |
Aug
(73) |
Sep
(121) |
Oct
(43) |
Nov
(27) |
Dec
(47) |
| 2004 |
Jan
(46) |
Feb
(90) |
Mar
(97) |
Apr
(87) |
May
(71) |
Jun
(103) |
Jul
(61) |
Aug
(15) |
Sep
(49) |
Oct
(32) |
Nov
(26) |
Dec
(4) |
| 2005 |
Jan
(33) |
Feb
(15) |
Mar
(27) |
Apr
(21) |
May
(29) |
Jun
(20) |
Jul
(16) |
Aug
(10) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
|
| 2006 |
Jan
(2) |
Feb
(9) |
Mar
(2) |
Apr
(7) |
May
(20) |
Jun
|
Jul
|
Aug
(13) |
Sep
(20) |
Oct
(11) |
Nov
(10) |
Dec
(7) |
| 2007 |
Jan
(12) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
(2) |
| 2008 |
Jan
(10) |
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(1) |
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Christopher W. <cr...@ms...> - 2005-04-07 07:01:54
|
I just threw together the other 5. I'm not checking it in myself because I'm only 99% sure it's right, mainly because I've never touched the unpacker before, but it was easy enough. I also fixed the function that was just added (GLenum was used in all the READ_DATAs, instead of each variable's type) ahh.. insomnia =) -Chris Brian Paul wrote: > > Greg Humphreys wrote: > >> Yeah, I only did the one that he needed. The other 5 are still >> unimplemented. > > > OK, I've added this as a TO-DO item so we don't totally forget about it. > > -Brian > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Chromium-dev mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-dev > |
|
From: Brian P. <bri...@tu...> - 2005-04-06 18:40:24
|
Greg Humphreys wrote: > Yeah, I only did the one that he needed. The other 5 are still unimplemented. OK, I've added this as a TO-DO item so we don't totally forget about it. -Brian |
|
From: Greg H. <hu...@gm...> - 2005-04-06 18:33:05
|
Yeah, I only did the one that he needed. The other 5 are still unimplemented. On Apr 6, 2005 2:29 PM, Brian Paul <bri...@tu...> wrote: > Kevin T Dale wrote: > > > >>-----Original Message----- > >>From: chr...@li... [mailto:chromium-dev- > >>ad...@li...] On Behalf Of Greg Humphreys > >>Sent: Tuesday, April 05, 2005 9:03 AM > >>To: chr...@li...; Kevin T Dale > >>Subject: [Chromium-dev] several bugs in pack/unpacking of textures > > > > > > > >>I fixed the packing functions, and wrote the unpacker for the one > >>function that Kevin was using. Kevin, would you mind sending the list > >>the fixed pack_texture.c and unpack_texture.c so someone could check > >>them in (the changes are on his personal machine). > > > > > > Attached. > > I've checked in your changes, plus an update to unpacker_special. > > It looks like the unpack routines for compressed 1D and 3D textures > weren't updated though. > > -Brian > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Chromium-dev mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-dev > > -- Greg Humphreys, Assistant Professor Department of Computer Science, University of Virginia http://www.cs.virginia.edu/~humper/ |
|
From: Brian P. <bri...@tu...> - 2005-04-06 18:27:38
|
Kevin T Dale wrote: > >>-----Original Message----- >>From: chr...@li... [mailto:chromium-dev- >>ad...@li...] On Behalf Of Greg Humphreys >>Sent: Tuesday, April 05, 2005 9:03 AM >>To: chr...@li...; Kevin T Dale >>Subject: [Chromium-dev] several bugs in pack/unpacking of textures > > > >>I fixed the packing functions, and wrote the unpacker for the one >>function that Kevin was using. Kevin, would you mind sending the list >>the fixed pack_texture.c and unpack_texture.c so someone could check >>them in (the changes are on his personal machine). > > > Attached. I've checked in your changes, plus an update to unpacker_special. It looks like the unpack routines for compressed 1D and 3D textures weren't updated though. -Brian |
|
From: Kevin T D. <kd...@cs...> - 2005-04-06 17:00:30
|
> -----Original Message----- > From: chr...@li... [mailto:chromium-dev- > ad...@li...] On Behalf Of Greg Humphreys > Sent: Tuesday, April 05, 2005 9:03 AM > To: chr...@li...; Kevin T Dale > Subject: [Chromium-dev] several bugs in pack/unpacking of textures > I fixed the packing functions, and wrote the unpacker for the one > function that Kevin was using. Kevin, would you mind sending the list > the fixed pack_texture.c and unpack_texture.c so someone could check > them in (the changes are on his personal machine). Attached. |
|
From: Brian P. <bri...@tu...> - 2005-04-05 15:24:10
|
Greg Humphreys wrote: > Kevin Dale and I discovered several bugs yesterday in the pack/unpack > functions for the Compressed texture extensions. There are 6 such > functions for 1,2,3D and full/sub textures. > > First of all, packing functions are never responsible for including > the packet length themselves. This is done implicitly by crPackAlloc. > This causes the unpacker to get confused because the packet looks > like: > > 4 bytes: length put there by crPackAlloc > 4 bytes: length (erroneously) put there by the packing function itself > 4 bytes: extended opcode > 4 bytes: texture target > ... > > etc > > but the unpacker tries to interpret the second four bytes as the > extended opcode and dies. > > Once we fixed this, we realized that the unpack versions of these > functions didn't exist. I'm not sure why there are pack functions > without corresponding unpack functions. They are very simple to > implement. Probably just an oversight. > I fixed the packing functions, and wrote the unpacker for the one > function that Kevin was using. Kevin, would you mind sending the list > the fixed pack_texture.c and unpack_texture.c so someone could check > them in (the changes are on his personal machine). > > Also, it seems that we have been lax about surrounding things with > #ifdefs for extensions. For example, we tried to undefine > CR_vertex_buffer_object, but this caused the state tracker to not > build because it unconditionally uses data structures that are > conditionally defined. Yeah, there's probably lots of instances of that problem. The original intention of those preprocessor symbols was to allow omitting extension code, but we've seldom actually tested that. -Brian |
|
From: Greg H. <hu...@gm...> - 2005-04-05 13:02:42
|
Kevin Dale and I discovered several bugs yesterday in the pack/unpack functions for the Compressed texture extensions. There are 6 such functions for 1,2,3D and full/sub textures. First of all, packing functions are never responsible for including the packet length themselves. This is done implicitly by crPackAlloc. This causes the unpacker to get confused because the packet looks like: 4 bytes: length put there by crPackAlloc 4 bytes: length (erroneously) put there by the packing function itself 4 bytes: extended opcode 4 bytes: texture target ... etc but the unpacker tries to interpret the second four bytes as the extended opcode and dies. Once we fixed this, we realized that the unpack versions of these functions didn't exist. I'm not sure why there are pack functions without corresponding unpack functions. They are very simple to implement. I fixed the packing functions, and wrote the unpacker for the one function that Kevin was using. Kevin, would you mind sending the list the fixed pack_texture.c and unpack_texture.c so someone could check them in (the changes are on his personal machine). Also, it seems that we have been lax about surrounding things with #ifdefs for extensions. For example, we tried to undefine CR_vertex_buffer_object, but this caused the state tracker to not build because it unconditionally uses data structures that are conditionally defined. -- Greg Humphreys, Assistant Professor Department of Computer Science, University of Virginia http://www.cs.virginia.edu/~humper/ |
|
From: Kevin T D. <kd...@cs...> - 2005-04-01 03:06:14
|
From: chr...@li... [mailto:chromium-dev- ad...@li...] On Behalf Of Brian Paul > You mean implementing the appfaker's pbuffer-related GLX functions, > right? I'm not exactly sure, but I suspect something could be whipped > up with a day's work. Yup, that's what I meant. This is actually something that I need here pretty soon. If somebody with a bit more chromium knowledge than myself can give me a quick-and-dirty on what needs to be done, I'll gladly whip this up. - Kevin |
|
From: Brian P. <bri...@tu...> - 2005-04-01 01:24:55
|
Kevin T Dale wrote: > > According to the release notes, v1.8 supports pbuffers. But to what extent? > I haven't been able to run an app that uses pbuffers successfully under > chromium, w/ a simple config w/ the render_spu on the app node. On windows, > I of course get a message that pbuffers aren't supported. And on linux, it > seems that the only thing I can do is force an app that would otherwise > render to the framebuffer to do so to an offscreen buffer, but it doesn't > seem like the app itself can use the GLX API for pbuffers. Right. The glXCreatePbuffer and related functions still aren't implemented. You can only pass the CR_PBUFFER_BIT to the crWindowCreate and crCreateContext functions to specify that you want off-screen rendering. > Is this the case? If not, please tell me what I'm missing here. If so, > what would be necessary to implement it for rendering from the app node? You mean implementing the appfaker's pbuffer-related GLX functions, right? I'm not exactly sure, but I suspect something could be whipped up with a day's work. -Brian |
|
From: Mike H. <mho...@gr...> - 2005-04-01 00:54:20
|
Raptor uses object space bounding boxes, NOT eye-space. However, you
need call glChromiumParametervCR every frame to force it to get the
current model view and projection matrices. The bounding box needs to
define the lower and upper edge of the bounding cube, i.e. the first
three values should be xmin, ymin, zmin of the box, and the last three
should be xmax, ymax, zmax. Each subvolume should have it's own bounds.
Once again, Raptor is a good model for how to do all of this, although
Brian Paul has seen some compositing problems on Nvidia hardware that I
have not been able to reproduce on ATI hardware...
We probably should be a little smarter in the binaryswap spu about
redoing the bounding box calculations each frame, but I remember trying
to do it on every application frame swap and it not working correctly
for all apps....
-Mike
Joong-Youn Lee wrote:
> Hi,
> I'm writing sort-last parallel volume rendering code using Chromium.
> I use the binaryswap SPU for compositing but have a trouble to set a
> bouding box.
> I thought the only thing needed is to set a object space bounding box
> and register it with glChromiumParametervCR function.
> My volume renderer is based on 3D texture method so I just set the box
> for all proxy planes.
> It works for initial condition - no modelview transformation - but it
> behaves strangely when I start to rotate the volume data (of course
> bounding box, too).
> Only partial images are displayed, I guess it's because the clip
> window function cut my rendering image.
> I've searched whole Chromium documents and mailing lists, but I didn't
> find any details how to set the use-defined bounding box.
> So I set the box with my own way - {{-1. -1. -1}. {1, 1, 1}}. and the
> geometry of proxy cube (set of proxy plane) is same.
> I also referenced the raptor and it seems to use eye space bounding
> box not object space bounding box. Is it right? Am I correctly understand?
> What should be a problem? Please advise me if you have any idea.
> Thank you in advance.
> Joong from Korea.
|
|
From: Kevin T D. <kd...@cs...> - 2005-04-01 00:54:00
|
According to the release notes, v1.8 supports pbuffers. But to what extent? I haven't been able to run an app that uses pbuffers successfully under chromium, w/ a simple config w/ the render_spu on the app node. On windows, I of course get a message that pbuffers aren't supported. And on linux, it seems that the only thing I can do is force an app that would otherwise render to the framebuffer to do so to an offscreen buffer, but it doesn't seem like the app itself can use the GLX API for pbuffers. Is this the case? If not, please tell me what I'm missing here. If so, what would be necessary to implement it for rendering from the app node? Thanks, Kevin |
|
From: Brian P. <bri...@tu...> - 2005-03-31 15:02:12
|
I had fixed a similar problem in the glloader.c file, but missed this. This is actually an interesting issue. The SYSTEM_LIB_DIR value should either be /usr/lib/ or /usr/lib64/ depending on whether the application is 32 or 64-bit. But I'm not sure how to determine that from within the crappfaker. The crappfaker uses fork() to spawn the application. So crappfaker could be 32-bit while the application is 64-bit, or vice versa. If we were to assume that the crappfaker and application were both 32 or 64-bit that would simplify things. I'd have to study the appfaker.c code for a while. I've never touched it before. Ideas are welcome. -Brian Abhijit Gadgil wrote: > Actually the problem is - > > In the app_faker/app_faker.c the SYSTEM_LIB_PATH is set to "/usr/lib" even for > x86_64, which should be /usr/lib64. > > Changing that, things work without a symlink. (I was using Mesa OpenGL) > > Thanks > > -abhijit > > > > --- Brian Paul <bri...@tu...> wrote: > >>Abhijit Gadgil wrote: >> >>>Hi all, >>> >>>I am using the latest chromium (1.8) on AMD Opteron motherboard. The >> >>problem I >> >>>am facing is as follows - >>>When any application is started using crdemo.conf file, the mothership runs >>>properly and the crserver runs properly. However, when crappfaker is >> >>invoked >> >>>following different behavior is observed in two different scenarios >>> - When /usr/lib64/libGL.so is symlinked to /usr/lib/ the crappfaker runs >>>properly. >>> - When /usr/lib64 is not symlinked to /usr/lib/libGL.so the crappfaker is >>>running as the application would run when fired from a command line. >>> >>>Strangely enough in the glloader.c systemPath is shown as /usr/lib64, which >>>means that there is no dependency on /usr/lib/libGL.so >>> >>>Can anyone throw some light on this? >> >>I assume you compiled Chromium in 64-bit mode. >> >>Is /usr/lib/libGL.so a 64-bit library? >> >>Whose OpenGL are you using? >> >>With the NVIDIA drivers, you should have both 32 and 64-bit libraries >>in the /usr/lib/ and /usr/lib64/ directories, respectively. There >>should be no reason to make symlinks. >> >>-Brian >> > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Small Business - Try our new resources site! > http://smallbusiness.yahoo.com/resources/ > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Chromium-users mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-users > |
|
From: Mike H. <mho...@gr...> - 2005-03-31 01:26:25
|
This version has been updated to work with Cr 1.8 and newer. It also contains a fix for a small dataset offset bug (thanks Brian!). You can find the code, datafiles, and example configs at http://graphics.stanford.edu/raptor. There are pending updates from Stanford Radiology and others, but this version should at least get things working again with Cr 1.8 Brian Paul has also been nice enough to provide a conf file that will auto partition things for a cluster. It hasn't been fully tested on complex configuration, but it seems to work for small setups at least. It takes the pain of partitioning and figuring out the binaryswap ordering. -Mike |
|
From: Brian P. <bri...@tu...> - 2005-03-26 01:02:24
|
Peter Djeu wrote: > I've attached a file that contains two small fixes for version 1.8 on > Windows. > > 1) > include/cr_threads.h > > On Windows, need to include "cr_bits.h" for the symbol CR_MAX_CONTEXTS. > > 2) > crutproxy/main.c > > Shadowing problem where each "if" block tried to copy the variable msg > into its own local copy with the same name. The "if" block variables > are now renamed to avoid uninitialized variable warnings / errors. Thanks, Peter. I'll check in your fixes soon. -Brian |
|
From: Peter D. <dj...@cs...> - 2005-03-26 00:55:11
|
I've attached a file that contains two small fixes for version 1.8 on
Windows.
1)
include/cr_threads.h
On Windows, need to include "cr_bits.h" for the symbol CR_MAX_CONTEXTS.
2)
crutproxy/main.c
Shadowing problem where each "if" block tried to copy the variable msg
into its own local copy with the same name. The "if" block variables are
now renamed to avoid uninitialized variable warnings / errors.
Sincerely,
Peter Djeu |
|
From: Brian P. <bri...@tu...> - 2005-03-25 14:52:31
|
Jorge Luis Williams wrote: > I don't think tilesort_dlpack_ignore_special should be in .cvsignore(?) I'll fix that. The .cvsignore files shouldn't be in the tarball either. -Brian |
|
From: Jorge L. W. <jo...@jl...> - 2005-03-25 06:52:16
|
I don't think tilesort_dlpack_ignore_special should be in .cvsignore(?) -jOrGe W. On Thu, 2005-03-24 at 09:16, Brian Paul wrote: > I've uploaded Cr 1.8 to the website. It can be downloaded at > > http://sourceforge.net/project/showfiles.php?group_id=16529&package_id=14422&release_id=315273 > > > This release probably hasn't been quite as well-tested as previous > releases (for lack of time). But the release is long overdue. I > don't think there'll be any serious issues, but I'll try to fix any > that might be discovered. > > -Brian > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Chromium-dev mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-dev > |
|
From: Brian P. <bri...@tu...> - 2005-03-24 17:14:35
|
I've uploaded Cr 1.8 to the website. It can be downloaded at http://sourceforge.net/project/showfiles.php?group_id=16529&package_id=14422&release_id=315273 This release probably hasn't been quite as well-tested as previous releases (for lack of time). But the release is long overdue. I don't think there'll be any serious issues, but I'll try to fix any that might be discovered. -Brian |
|
From: Brian P. <bri...@tu...> - 2005-03-23 03:19:55
|
Aditya Kulkarni wrote: > Hi all, > > I am running Suse Linux 9.1. I tried compiling replicate spu from the > latest cvs checkout. Found a problem at line 215 in > replicatespu_redirect.c - > > XVncChromiumStart(replicate_spu.glx_display, ipaddress, > CHROMIUM_START_PORT + r_slot, mothershipPort); > > I found that XVncChromiumStart takes only 3 parameters. Here 4 > parameters are being passed. Would request you to make the necessary > changes and commit the same. If you get the latest xf4vnc sources from CVS this shouldn't be a problem. -Brian |
|
From: Brian P. <bri...@tu...> - 2005-03-23 03:19:08
|
When I wrote the SPU, I had to modify the code which encodes the framebuffer image to deal with bottom-to-top raster order (to match OpenGL). I guess I didn't finish that job for all the different encodings. That's probably the problem. Unfortunately, I really don't have any time to fix that right now. -Brian Aditya Kulkarni wrote: > Hi all, > > Managed to get VNC spu running, but I found a strange problem with it. > > When a vncviewer (default one shipped with SuSe linux 9.1, v1.2.9) > connects to the vncserver started by vncspu, an assertion > (RASTER_BOTTOM_TO_TOP == 0) fails in translate.c in spu/vnc directory. > > This problem does not necessarily occur everytime. > - When the vncviewer and vncserver are on the same host, it doesnt occur. > - When vncviewer and vncserver are on different 32-bit hosts, the > problem doesnt occur. > - When the vncviewer is on a 64-bit host, and the vncserver on 32-bit > host, this problem occurs. > > Any clue whats the root cause of the problem and whats the solution? > > Thanks, > Aditya Kulkarni > > On Mon, 21 Mar 2005 15:52:07 +0530, Aditya Kulkarni > <adi...@gm...> wrote: > >>Hi all, >> >>I have the following chromium set up on a suse linux box - >> >>1> An application node has a vnc spu attached to it. >>2> The chromium mothership and the crappfaker run on the same host. >>3> Making use of "atlantis". >> >>I am not able to see any image in the window opened by vncviewer >>(tightvnc). I checked that vnc spu was able to start a listener at >>port 5905 on the localhost, and even accept connections from a >>vncviewer. However, it gave the following errors on different >>occassions - >> >>[1] Error sending to 10.1.2.8 - Broken Pipe >>[2] Error reading from 10.1.2.8 >> >>What can I do to make it work? Am I missing something grossly? >>-- >>Best Wishes, >>Aditya Kulkarni >> > > > |
|
From: Aditya K. <adi...@gm...> - 2005-03-22 10:23:15
|
Hi all, Managed to get VNC spu running, but I found a strange problem with it. When a vncviewer (default one shipped with SuSe linux 9.1, v1.2.9) connects to the vncserver started by vncspu, an assertion (RASTER_BOTTOM_TO_TOP == 0) fails in translate.c in spu/vnc directory. This problem does not necessarily occur everytime. - When the vncviewer and vncserver are on the same host, it doesnt occur. - When vncviewer and vncserver are on different 32-bit hosts, the problem doesnt occur. - When the vncviewer is on a 64-bit host, and the vncserver on 32-bit host, this problem occurs. Any clue whats the root cause of the problem and whats the solution? Thanks, Aditya Kulkarni On Mon, 21 Mar 2005 15:52:07 +0530, Aditya Kulkarni <adi...@gm...> wrote: > Hi all, > > I have the following chromium set up on a suse linux box - > > 1> An application node has a vnc spu attached to it. > 2> The chromium mothership and the crappfaker run on the same host. > 3> Making use of "atlantis". > > I am not able to see any image in the window opened by vncviewer > (tightvnc). I checked that vnc spu was able to start a listener at > port 5905 on the localhost, and even accept connections from a > vncviewer. However, it gave the following errors on different > occassions - > > [1] Error sending to 10.1.2.8 - Broken Pipe > [2] Error reading from 10.1.2.8 > > What can I do to make it work? Am I missing something grossly? > -- > Best Wishes, > Aditya Kulkarni > -- Best Wishes, Aditya Kulkarni |
|
From: Aditya K. <adi...@gm...> - 2005-03-22 10:17:03
|
Hi all, I am running Suse Linux 9.1. I tried compiling replicate spu from the latest cvs checkout. Found a problem at line 215 in replicatespu_redirect.c - XVncChromiumStart(replicate_spu.glx_display, ipaddress, CHROMIUM_START_PORT + r_slot, mothershipPort); I found that XVncChromiumStart takes only 3 parameters. Here 4 parameters are being passed. Would request you to make the necessary changes and commit the same. -- Thanks, Aditya Kulkarni |
|
From: Aditya K. <adi...@gm...> - 2005-03-21 10:22:16
|
Hi all, I have the following chromium set up on a suse linux box - 1> An application node has a vnc spu attached to it. 2> The chromium mothership and the crappfaker run on the same host. 3> Making use of "atlantis". I am not able to see any image in the window opened by vncviewer (tightvnc). I checked that vnc spu was able to start a listener at port 5905 on the localhost, and even accept connections from a vncviewer. However, it gave the following errors on different occassions - [1] Error sending to 10.1.2.8 - Broken Pipe [2] Error reading from 10.1.2.8 What can I do to make it work? Am I missing something grossly? -- Best Wishes, Aditya Kulkarni |
|
From: Greg H. <hu...@gm...> - 2005-03-17 16:36:11
|
Yes, GDI calls wgl, but the problem is that if our faker library is loaded, WE are wglSetPixelFormat, and so if we call the GDI one, it calls us, which calls the GDI one, which calls us, which... etc. On Thu, 17 Mar 2005 08:56:05 -0700, ma...@co... <ma...@co...> wrote: > > > in particular, it's calling the wglSetPixelFormat call (instead of the > > GDI SetPixelFormat call) even if the render spu is on the server. > > If I understand things correctly, the GDI SetPixelFormat call ends up calling > the driver's wglSetPixelFormat function anyway... right? > > (In a bit over my head at this point) > > Let us know if you get it worked out... since we're doing windows work at our > VR facility (BP Center for Visualization, University of Colorado) it could be > useful for us too. > > Incidentally, what are you trying to do with Doom3? A tiled wall? A cave? (Ooh > that would make a great demo...) > > Jon > > > Quoting Greg Humphreys <hu...@gm...>: > > > Incidentally, Kevin Dale and I are having some issues with the way > > renderspu_wgl.c is handling pixelformat calls as well -- in > > particular, it's calling the wglSetPixelFormat call (instead of the > > GDI SetPixelFormat call) even if the render spu is on the server. > > > > My understanding was that we only called the wgl one directly if we > > were loaded by the faker, to avoid an infinite loop. Anyhow, I agree > > that there's something fishy going on with wgl and pixelformats, > > particularly when trying to run doom3. > > > > On Thu, 17 Mar 2005 08:09:47 -0700, ma...@co... > > <ma...@co...> wrote: > > > Peter, > > > > > > Re: hacking wgl.c - That's what we've been doing as well... for the moment, > > > hacking it to make a particular app happy is what we've been doing as well. > > > > > > What I've learned so far is that some apps like to see a software > > PixelFormat > > > available before finding a HW accelerated pf. (SketchUp, an architectural > > > design program is one app in particular.) So one thing we should do (at > > some > > > point) is have Chromium expose a few PixelFormats so that apps that are > > > designed to choose from a few have something to work with. We don't have to > > > actually have chromium honor the differences in pixel format, of course... > > > > > > We've also added a -notemp option to crappfaker so that it doesn't do the > > file > > > copying to a temp directory. The code isn't clean enough right now to put > > back > > > into the tree but it has helped us get a few apps going that were looking > > for > > > files in particular relative locations. > > > > > > Jon > > > > > > ps. After rereading your message, the chromium render SPU is choosing > > > PixelFormat 1...? Wierd. Hmmm, I haven't seen that problem. The app should > > be > > > choosing PixelFormat 1 but the render SPU... Well I guess if you got it > > > working I won't sweat it. > > > > > > > > > ------------------------------------------------------- > > > SF email is sponsored by - The IT Product Guide > > > Read honest & candid reviews on hundreds of IT Products from real users. > > > Discover which products truly live up to the hype. Start reading now. > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > > _______________________________________________ > > > Chromium-dev mailing list > > > Chr...@li... > > > https://lists.sourceforge.net/lists/listinfo/chromium-dev > > > > > > > > > > > > -- > > Greg Humphreys, Assistant Professor > > Department of Computer Science, University of Virginia > > http://www.cs.virginia.edu/~humper/ > > > > -- Greg Humphreys, Assistant Professor Department of Computer Science, University of Virginia http://www.cs.virginia.edu/~humper/ |
|
From: <ma...@co...> - 2005-03-17 15:56:32
|
> in particular, it's calling the wglSetPixelFormat call (instead of the > GDI SetPixelFormat call) even if the render spu is on the server. If I understand things correctly, the GDI SetPixelFormat call ends up calling the driver's wglSetPixelFormat function anyway... right? (In a bit over my head at this point) Let us know if you get it worked out... since we're doing windows work at our VR facility (BP Center for Visualization, University of Colorado) it could be useful for us too. Incidentally, what are you trying to do with Doom3? A tiled wall? A cave? (Ooh that would make a great demo...) Jon Quoting Greg Humphreys <hu...@gm...>: > Incidentally, Kevin Dale and I are having some issues with the way > renderspu_wgl.c is handling pixelformat calls as well -- in > particular, it's calling the wglSetPixelFormat call (instead of the > GDI SetPixelFormat call) even if the render spu is on the server. > > My understanding was that we only called the wgl one directly if we > were loaded by the faker, to avoid an infinite loop. Anyhow, I agree > that there's something fishy going on with wgl and pixelformats, > particularly when trying to run doom3. > > On Thu, 17 Mar 2005 08:09:47 -0700, ma...@co... > <ma...@co...> wrote: > > Peter, > > > > Re: hacking wgl.c - That's what we've been doing as well... for the moment, > > hacking it to make a particular app happy is what we've been doing as well. > > > > What I've learned so far is that some apps like to see a software > PixelFormat > > available before finding a HW accelerated pf. (SketchUp, an architectural > > design program is one app in particular.) So one thing we should do (at > some > > point) is have Chromium expose a few PixelFormats so that apps that are > > designed to choose from a few have something to work with. We don't have to > > actually have chromium honor the differences in pixel format, of course... > > > > We've also added a -notemp option to crappfaker so that it doesn't do the > file > > copying to a temp directory. The code isn't clean enough right now to put > back > > into the tree but it has helped us get a few apps going that were looking > for > > files in particular relative locations. > > > > Jon > > > > ps. After rereading your message, the chromium render SPU is choosing > > PixelFormat 1...? Wierd. Hmmm, I haven't seen that problem. The app should > be > > choosing PixelFormat 1 but the render SPU... Well I guess if you got it > > working I won't sweat it. > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > Chromium-dev mailing list > > Chr...@li... > > https://lists.sourceforge.net/lists/listinfo/chromium-dev > > > > > > > -- > Greg Humphreys, Assistant Professor > Department of Computer Science, University of Virginia > http://www.cs.virginia.edu/~humper/ > |
10 messages has been excluded from this view by a project administrator.
