glc@frame.UUCP (Greg Cockroft) (07/27/89)
The NeXT manuals do not document how to get at screen bits. I want to make a fancy info box for FrameMaker, and I want to write directly into screen bits. Personally I refuse to buy one of these boxes unless they change their minds about documenting this stuff. Does anyone know how to do this? I have resorted to disassembling the windowserver. The binaries are stripped, but the shared libraries make life a little easier. Symbols show up when you enter system function stubs. Anyway here's how far I've gotten, and I would appreciate any help. strings WindowServer | grep dev shows that /dev/ev0 & /dev/vid0 are the devices used. Then I used otool to disassemble /usr/lib/NextStep/WindowServer. Then I used gdb on the executable and set breakpoints in open & ioctl, to get their addresses. Then I did global replaces in the assembler output to mark the calls. Here is what is going on. /dev/vid0 is opened. DKIOCGADDR ioctl is used on the fd. see /usr/include/nextdev/video.h 120 bytes of memory are allocated. The beginning and ending addresses are shoved in a struct mwf data structure, and an DKIOCSMWF ioctl is executed. The mwf struct is worked on and the following numbers are computed and shove into some globals. 0x10000000 0x14000000 0x18000000 0x1c000000 This is as far as I've gotten. Does anyone know what is going on? -greg.
jgreely@oz.cis.ohio-state.edu (J Greely) (07/27/89)
In article <3562@frame.UUCP> glc@frame.UUCP (Greg Cockroft) writes: >The NeXT manuals do not document how to get at screen bits. >I want to make a fancy info box for FrameMaker, and I want to write >directly into screen bits. Personally I refuse to buy one of these >boxes unless they change their minds about documenting this stuff. Personally, if the only way you can do what you want is by ignoring *all* of the graphics support provided by NeXT, I refuse to buy your product. So there. What exactly are you trying to do? If you've managed to identify something that's impossible or extremely difficult to accomplish with the current graphics libraries, I'm interested in knowing what it is, and I'm sure NeXT is, too. Of course, I want the frame buffer information, too, but I want to do things like port MGR and screen hacks. The screen hacks are for fun, and MGR is for an odd form of political commentary. "Look, Max! It's those pyramid- building aliens I've heard about in speculative films and books! They came to Earth to build these immense structures to keep their razor blades sharp and their hamburger fresh." -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
greid@adobe.com (Glenn Reid) (07/28/89)
In article <3562@frame.UUCP> glc@frame.com (Greg Cockroft) writes: >The NeXT manuals do not document how to get at screen bits. >I want to make a fancy info box for FrameMaker, and I want to write >directly into screen bits. Personally I refuse to buy one of these >boxes unless they change their minds about documenting this stuff. ... >This is as far as I've gotten. Does anyone know what is going on? I know what's going on. With all due respect, you are barking up the wrong tree. To paraphrase James Gosling, "Pixels are bad for you." You have the entirety of Display PostScript at your disposal for drawing fancy boxes. Poking values into screen memory to draw is exactly counter to the philosophy of the whole window manager and screen display system, which is why you can't find it documented anywhere, I believe. Techniques like that are also almost guaranteed not to work on different screens or in various other environments. Just out of curiosity, what is the fancy effect you are trying to achieve that neither Display PostScript nor compositing can do for you? Just kibbitzing, Glenn Reid Adobe Systems
jpd00964@uxa.cso.uiuc.edu (07/28/89)
> the need to get to the screen bits > and the reply that said he would not buy his product I agree with the lack of desire to look into such a product. All one has to do is remember scene from system 0.8 which no longer works with system 0.9. My understanding was that it stopped working because it was originally made with such hacks that broke rather quickly. However, a way to still do what is wanted is to just create a window that is the size of the screen and place it in the window list behind all other windows. > not buying a cube because such information is not available C'mmon, they are still on system 0.9. Half the stuff I do is not documented yet. If you want all the information given to you on a silver platter, then maybe you should wait a year or two. Michael Rutman Softmed
glc@frame.UUCP (Greg Cockroft) (07/28/89)
>I know what's going on. With all due respect, you are barking up >the wrong tree. To paraphrase James Gosling, "Pixels are bad for >you." Yes, but even NeWS ended up with the setrasteropcode operator, because the ideal is not always practical. >Just out of curiosity, what is the fancy effect you are trying to >achieve that neither Display PostScript nor compositing can do for >you? I want to have multiple greyscale images flipping simultaneously on the screen in realtime. The only way to do this in NeXTSTep is to create all the images ahead of time and composite them onto the screen. Here is another example where anti-pixel paranoia is harmful. With the removal of initwindowalpha in 0.9, there is no way to invert a rectangle quickly in NeXTStep. FrameMaker inverts rectangles around objects for object manipulation, because it is non-destructive to possible objects drawn underneath. The alternate way to do objects handles is to damage the area underneath. This works fine if nothing complex is damaged, but in alot of cases this is very slow. -greg.
glc@frame.UUCP (Greg Cockroft) (07/28/89)
>Personally, if the only way you can do what you want is by ignoring >*all* of the graphics support provided by NeXT, I refuse to buy your >product. So there. I'm not ignoring anything. There are some things that DPS is just not fast enough to do in real time. Not because it is slow, but because it is general. I stated in the previous message that the application is a *neat* info box. It has nothing to do with the functionality of FrameMaker, so if it is a noop on new display buffers, nothing is lost. -greg.