Re: [Xpert] 4.2.99.3 pointer color red?
Around 0 o'clock on Dec 31, Jeff Chua wrote: > How can I change "red" pointer color in XFree86 4.2.99.3? You can switch to another cursor theme with an X resource: Xcursor.theme: whiteglass will select the other theme provided in current XFree86 sources. I'm very interested in getting some more cursors for XFree86 4.3; I keep hoping we'll find someone able to do a better job than me. I've solicited many people without success to date... Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]4.2.99.3 pointer color red? (fwd)
Around 19 o'clock on Jan 1, Alejandro Lorenzo wrote: > What are the tools needed for make an own cursor? Any painting or drawing program. > I mean, what's the format in which the cursor are saved? how can we make ours? The Xcursor library uses a custom format (.cur) for the cursor files. XFree86 includes a tool (xcursorgen) that takes a set of .png files along with a configuration (.cfg) file and generates .cur files. Each .cur file contains a set of cursors at different sizes, each size can include multiple images which will be used as an animation (the xcursorgen manual doesn't mention that a delay in ms can be added at the end of the .cfg entry for each image). Use the existing redglass directory as an example. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]About the XFree 4.2.99 snapshot and the whiteglass theme cursor
Around 3 o'clock on Dec 31, Alejandro Lorenzo wrote: > and i realize of a "problem" if you use the "whiteglass" theme and you > have a black-like background (or in any app) you can see how appears a > vertical black line in the cursor which isn't very elegant... :-/ I think that's just an artifact of the scaling used on the cursor images; help in cleaning that up would be appreciated. > Oh!, by the way, i wanted to make a screenshot to ilustrate whay i was > talkin about but the cursor doesn't appears in the ksnapshot's shot No cursor image ever appears in a screenshot. It's not logically a part of the screen image, and may in fact be implemented in separate hardware and never even be stored in the frame buffer. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]4.2.99.3 pointer color red? (fwd)
Around 3 o'clock on Dec 31, Alejandro Lorenzo wrote: > I was wondering what other themes are avaible for the mouse in this new > release ??? We've only got the two related semi translucent themes (redglass and whiteglass). I'd like to see at least a couple more, especially one which used only two colors + transparent for each cursor so that older hardware could use themed cursors without being forced to use software cursors. It's easy enough to build a single cursor, it's just very tedious to build many related cursors and then scale them to a reasonable set of sizes. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]How do I make my colors _perfect_?
Around 15 o'clock on Dec 17, Dr Andrew C Aitchison wrote:
> Xcms is the only existing technology for this that I'm aware of -
> "man xcmsdb XcmsCreateCCC" may be a reasonable starting point.
>
> I believe that Keith Packard thinks that it should be replaced.
> Here is a list of things I've learnt about Xcms over the years:
The X Color Management SYstem (Xcms) is built upon the X Device Color
Characterization Convention (XDCCC) which is part of the ICCCM spec and
involves a pair of properties set on the root window which contain tables to
convert between pixel RGB values and intensity ("gamma" correction) and
matrices for mapping between this linear RGB to CIE XYZ.
Xcms then takes this information and exposes several CIE traceable color
spaces, such as CIE XYZ, CIE uvY, CIE xyY, CIE Lab, CIE Luv and the
Tektronix HVC color space as well as both the original non-linear monitor
RGB and the "gamma" corrected linear RGB space.
The only problem with Xcms is that it's integrated into Xlib in a useless
fashion; it allows the specification of colors in any of these color
spaces in string form through the regular Xlib color name APIs. This
means that Xlib is burdened with all of Xcms.
In addition, Xcms makes it somewhat difficult to add new color spaces and
doesn't expose the underlying XDCCC data structures to applications.
Because the typical monitor used for X has no color calibration data,
application developers never saw value in this complicated color managment
mechanism and hence never really adopted any of it's functionality.
I think the underlying monitor calibration data is sound, but what we
should do is look again at what API should be exposed to applications to
take advantage of this calibration information, in particular I can see
value in adding several new color spaces such as sRGB. I would also like
to see the Render extension include gamma corrected compositing operations
using the gamma tables provided through XDCCC.
Xcms includes extensive support for automatic gamut compression; I don't
have enough experience with that part of the API to know if it's useful or
not; it's a hard problem with significant data dependencies.
> 2) Xcms uses its own trig routines for Polar<->Cartesian conversion
> between color-spaces*, and these are buggy.
Sigh. Of course that was forced because Xcms is integrated into Xlib and
it wasn't possible to require applications to link against the math
library just to use Xlib; systems without chained library dependencies
were more common 10 years ago than they are today.
> but my experience, and perceived wisdom, is that on average using the
> default setup gives more accurate color than trusting the info provided by
> the monitor itself
I recall the results of that experiment -- assuming a standard gamma of
2.2 was more accurate on average than believing the DDC gamma values. I
must assume that's true because Windows doesn't expose that data to
applications. I've heard that DDC information on "mac friendly" monitors
is significantly more accurate.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFIXES extension proposal
Around 16 o'clock on Dec 6, Juliusz Chroboczek wrote: > Thanks. The performance issue is clear. What's the semantics problem? One obvious issue is that transfering selection owner would allow only a single application to track the selection contents. Another involves targets with side effects (DELETE, INSERT_SELECTION and INSERT_PROPERTY). These couldn't be correctly executed by a secondary agent. A third is that the external agent would have to understand the data format and content of every possible selection target to avoid losing the format of interest between two clients. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFIXES extension proposal
Around 21 o'clock on Dec 3, Juliusz Chroboczek wrote: > Why can't klipper take the ownership of the selection, as xclipboard > does ? PRIMARY semantics don't really permit that, and it's a large performance problem for some selection types (ever done cut&paste in the gimp?); to fully support selection content, you'd have to fetch every possible representation of the data and store it in a separate agent. Also, 'klipper' doesn't generally advertise PRIMARY; one of it's many uses is as a passive "assistant" where it monitors the contents of PRIMARY and suggestions actions based on them -- select 'http://...' and klipper offers to launch mozilla for you. For that operation, it just wants the contents in text form, but prefers to leave the actual selection resident in the original application. Remember that one of the chief benefits of selections is that the data doesn't actually get transfered through the X server until it's requested, so applications are free to advertise selections for things which will probably not ever be copied to another client. > (I'm not arguing against this extension, as I think that making > client-visible state changes observable is a Good Thing. Just idle > curiosity.) I've struggled with the current protocol for 15 years without this notification; there's no doubt in my mind that it's a good idea. I'm not the originator here either, although I'm a bit fuzzy as to whether it was Havoc Pennington or Owen Talyor that suggested it a couple of weeks ago. One of the problems of doing design meetings via IRC is that you don't automatically get a permanent record. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]server time
Around 17 o'clock on Dec 2, David Fries wrote: > Is there any way to get the server timestamp without waiting for an > event or using the last event? Change a property and wait for the PropertyNotify event. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFIXES extension proposal
Around 21 o'clock on Dec 1, [EMAIL PROTECTED] wrote: > No joy. :-( Poking around in xc/lib/Imakefile, I saw a conditional > with BuildXFixesLibrary, so I added " #define BuildXFixesLibrary No" > to config/cf/host.def and tried "make World" again. Still no joy, > but the breakage is slightly different: $ rm xmakefile $ make World should fix things. You'll want to leave Xfixes disabled; it won't be included in XFree86 4.3 as it really isn't ready yet. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFIXES extension proposal
Around 0 o'clock on Dec 1, Boris wrote: > What XFree *really* needs is much more data compression when sending data > to a remote display I'm doing some packet level analysis of this problem; at ethernet speeds, most X applications spend a lot more time waiting for round trips than they do waiting for space on the wire to transmit more packets. The only time this isn't true is during image transport, so some kind of image compression is clearly indicated. The kind of image compression (essentially PNG vs JPEG), it's interactions with Render and shared memory are still unresolved issues my view. > The X protocol uses alot of Bandwidth when dealing with *alot* of clients. That's not always true; applications sending a lot of images do consume some transient bandwidth, but many applications can be easily run with 128Kb or less of bandwidth. X applications are often very dependent on network latency for reasonable performance though, much of that dependence can be attributed to "sloppy" code in toolkits which don't always carefully avoid every round trip possible. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Adding InputRegion to SHAPE extension
X11 has two kinds of windows -- InputOnly and InputOutput. InputOnly windows receive mouse and keyboard events just like InputOutput windows but have no graphical content so that underlying windows show through them. InputOutput windows receive input and also occlude underlying windows. Missing from this list is the notion of a window which occuludes underlying windows but is transparent to mouse position; an "OutputOnly" window if you will. Now you'll all asking yourselves "what good is an output only window?". Well, consider the drop shadows of Aqua -- those are essentially windows which appear above other windows for the purpose of graphical output but wihch don't affect mouse input. We can add alpha components to windows, but without some way to modify the mouse clipping behaviour, we can't provide this kind of interface. I went and prototyped OutputOnly windows in the server and discovered that they really weren't as useful as I'd like -- because the window is invisible for puposes of input, it wouldn't be semantically consistent to make decendent windows receive input. So, to implement drop shadows, you'd have to place OutputOnly windows only where the drop shadows appeared and not where the regular application window did. Dragging and resizing would involve the syncronized configuration of several windows, something which always makes things look clunky. As a replacement, I looked at the Shape extension and decided that a very easy thing to do would be to add another region to each window, the "input region" which would clip input but not output. Place an input region covering the application area but not the drop shadow and suddenly everything works just fine. Adding an input region to the Shape extension would require only very minor changes, in particular, the current bounding and clip regions are named in the requests which modify them so only a new name would be required meaning no new requests would be needed. The changes in the DIX level are similarly straightforward -- a new per-window (in the WindowOptional) structure paralleling the current shape regions would be added and then XYtoWindow would be modified to respect that region. Confining the mouse on grabs requires a bit more work, but nothing significant. Most notably, there would be no effect below the DIX level. This would be something added after 4.3, so there's no particular schedule to be concerned about here. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFIXES extension proposal
Around 3 o'clock on Dec 1, James Hawtin wrote: > The only problem with the fixes extension will people use it, as they > will have to write the code twice so it supports "legancy" ie not Xfree86 > systems. (thinking of selection tracking here) That's been the argument against such extensions over the last 15 years, and it's certainly valid as far as it goes, but I think we can now look toward more rapid adoption of extensions in the general population, certainly rapidly enough to provide incentive for application developers to support the new mechanisms in addition to the old. > As kludges exist for some of these fixes, a compatibility library could be > made so people who wrote code in the "new" way, would have some kind of > support on other systems, but still could write things "clean", in the > case of selection tracking, it would do the polling, but return events as > if the XFIXES was there. Perhaps that would be possible at the toolkit level, but down at the protocol library level, there's no flow of control to manage timeouts and the like. As XFree86 doesn't really have control over the dominate toolkits, we'll have to see what those groups manage to implement, although we might give them some suggestions. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XFIXES extension proposal
We've been working around various problems with the core X protocol for about 15 years now. I think it's time to build an extension that includes small changes that fix big problems. Such an extension would be limited to problems with existing core functionality that can be easily fixed in the server but for which client side workarounds are kludgy or broken. I've got three proposed problems and fixes implemented already and would like to hear other issues of interest to the community. 1) XEMBED error recovery The XEMBED specification http://www.freedesktop.org/standards/xembed/html uses nested windows to place one application window within another. One of the authors (Owen Taylor) brought a problem with error recover in this model to my attention and proposed a solution. The problem is caused by how SaveSet processing is done within the X server during (abnormal) client termination. Normal SaveSet processing reparents (embedded) windows to the nearest enclosing non-client window. In an embedding environment, that will be the window manager frame holding the embedding application. The window manager won't expect new windows to suddenly appear in this context and (generally) ignores them and goes about destroying the frame which takes the embedded application window along with the frame. The proposal is to select the root window as the SaveSet target window so that the window manager simply sees them as regular windows. A further refinement is to permit these windows to remain unmapped instead of suddenly popping up on the screen. 2) Selection Tracking Applications like the KDE 'klipper' monitor selection contents to save them and also perform actions based on them. Right now, this happens by having these clients contantly polling the selection. The proposal is to have a event delivered whenever the selection changes. 3) Cursor Image Echoing Applications like VNC or screen magnifiers work by duplicating the contents of the screen, but cannot succesfully track the cursor image in the duplicate screen. This makes the forwarded environment harder to use as the cursor image often contains significant semantic content -- like the precise location of window borders or application state like busy/idle. The proposal is to have an event reported when the cursor image changes and a request to fetch the current cursor image. I've stuck these features into a new XFIXES extension and included that in XFree86 CVS so that others might see the code and specification and test whether they solve the issues they're supposed to. This does not represent any endorsement by the XFree86 project or it's members (other than me), nor any assurance that the extension will be included in future XFree86 releases. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [OFFTOPIC] spam scoring (was: [Xpert]*****SPAM***** Extracting a KeySym from an action routine)
Around 14 o'clock on Nov 26, David Dawes wrote: > All I can really say so far without having analysed the data is that > the number of false positives has been relatively small compared to the > number of valid positives. I need to assess now many valid positives > were attributable to the RBL matching before coming to any conclusions > about that. However, the false negative rate for xpert has been surprisingly high, compared to the results I've seen with spamassassin here at home. High enough to prevent me from automatically forwarding messages not tagged as spam sent by non-subscribers. There have been several spam detector papers submitted to this years Usenix conference; I'm pretty confident that we'll have better tools available in the next couple of months. We might disable the RBL based rules in flagging spam; they do seem to have a rather high false-positive rate. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Portrait Mode in X
Around 10 o'clock on Nov 25, "Mark Cuss" wrote: > The application that we plan to use displays decoded > MPEG2 that does a bunch of XvPutImage calls which would likely be pretty > slow if the X server had to rotate each frame in software The Mach64 "Tiny-X" driver supports rotated Xv overlays on top of a rotated shadow frame buffer for regular graphics. Performance is not a problem as the hardware is still doing the YUV->RGB and scaling. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Mouse Cursors
Around 10 o'clock on Nov 22, Carl Worth wrote: > Is the Xft.dpi resource intended to be the "logical dpi" as you > described: Yes, as noted: "Xft already uses a separately configurable value (Xft.dpi) that can be used to adjust the size of text on the screen." > If so, can we come up with a better name for it? A better name would use different units. I tend to think of "inches" as an angular measurement now :-) > Even "logical dpi" isn't a totally satisfying name. It does indicate > that something is going on other counting dots and dividing by length > in space, but it doesn't give me any help in figuring out what value I > should provide. "dpi" is a close as we currently get to a "well understood" metric for this value; I doubt very much you'd get anything other than blank stares if we used something like "dots per radian" or even "dots per degree". dpi also has the advantage of using relatively small numbers and mapping realtively closely to real dpi for most desktop environments. > In a reply to the message above, Andrew suggested, "dots per degree > ?". Is that what we want here? Yes, mostly. But not quite -- "degree" depends on distance to the viewer, and in environments with multiple viewers, that's not constant. And you want to take the rest of the display environment into account -- environments with significant vibration will need larger text; I'm sure there are other such examples. For now, we just need a slider that says "smaller <---> bigger" and a way to hook that into applications. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Mouse Cursors
Around 5 o'clock on Nov 22, John Tapsell wrote: > Sorry for being slow, but why isn't the display dpi good? > You could try to always make the cursor 1cm big for example - isn't that a > good thing? Mostly what you need is bigger cursors on bigger screens. Display DPI is a miserable metric for that; I use really small cursors on my 320x240 iPAQ which is well over 100dpi. At the same DPI on my 1600x1200 screen, I'd want a much bigger cursor. Of course, this is just the fallback; it uses the synthetic 'dpi' as set by the Xft.dpi resource in preference, and you can override both of those by explicitly setting the cursor size with Xcursor.size. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Mouse Cursors
Around 0 o'clock on Nov 22, John Tapsell wrote: > Could we have the cursor size be automatically set from the dpi? > Is it already? It's automatically set from Xft.dpi resource (if set), or from the smaller of DisplayWidth/48 or DisplayHeight/48. Display DPI isn't a very useful metric here, but the result of the above computation can generate some largish cursors on big xinerama screens, but only if you're tiling screens in 2D. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Builtin font path fallback
Kdrive uses a special font path 'built-ins' to handle the problem of bringing up the X server when the regular font path is hosed. This special font path element has four fonts compiled right in, so it need never touch the disk. Both 'fixed' and 'cursor' are always available, along with 5x7 and 5x8 for some historical reason. Should I stick these into the regular server so that it will never again fail to start due to a lack of fonts? Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Mouse Cursors
Around 15 o'clock on Nov 21, "Catherine Luedecker" wrote: > Speaking of cursors.are there other cursors available for X and where > are they located? We have two themes currently (redglass and whiteglass). If anyone else has cursor themes they'd like to add, please submit them and we'll ship 'em. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Mouse Cursors
Around 11 o'clock on Nov 21, Scott Lampert wrote: > Is there a simple way to get X to use larger or different mouse cursors? In current CVS, you can set the Xcursor.size resource to a number like 48 or 64 to increase the size of cursors. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Visuals, PixmapFormats and XImage
Around 17 o'clock on Nov 18, Tor Andersson wrote: > Second, I need a Visual in XCreateImage. Apparently, after testing, > this has to be the same as the Visual of the Window. No, you don't need a visual to create an image, just use NULL. As there aren't generally any depth 32 ARGB visuals available, you'd have a hard time finding one to match your image. > Third, bits per pixel is not advertised by the visual but can be inferred > by creating an image with XCreateImage and checking the bits_per_pixel field. > In the source to XCreateImage, _XGetBitsPerPixel is called and returns 32 for > both 24 and 32 bit deep visuals Visuals don't deal with wire pixel formats, so they don't have a bits-per-pixel. BitsPerPixel comes from the pixmap format values which you can get from XListPixmapFormats. Or, given that you're using depth 32 images, you can just assume 32 bits per pixel. As bpp must always be no less than depth and no greater than 32, this will always work. > Are the red/green/blue_masks specified in the word order of the X server, > and as such be swapped if client and server have different byte orders? You don't need to deal with the mask values stored in the XImage structure; they're strictly informative for applications using GetImage. The relevant mask information for Render images comes from the associated PictFormat structure. And, data seen by your application is always in the applications byte order. > Finally, what the hell is a DirectColor visual? The LUTs in most hardware can be programmed to change the mapping from R, G and B values in the pixels to R, G, and B values sent to the DAC. DirectColor exposes this mapping as a writable colormap. Render ignores this mapping and just exposes the pixel values as if they were mapped directly to the DAC inputs, so it's not very productive to use a DirectColor visual with Render applications, unless you load the LUT with some kind of non-decreasing sequence. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]HW Rotation
Around 12 o'clock on Nov 11, Luugi Marsan wrote: > We are thinking of implementing hw accelerated rotated screen. Anybody > have any ideas on how we could implement this? The RandR extension permits this, and I'm working on the XFree86 RandR support to provide for hardware supported rotation. I've hacked in software rotation support, but that isn't going into XFree86 anytime soon as there are conflicts with XAA, Xv and GLX. Hardware support is significantly easier. The only requirement will be to allocate a square frame buffer area so that rotation doesn't affect the 2D pixmap allocator used by the current acceleration architecture. When I receive hardware (promised, but not delivered), I'll get this running. Alternatively, if you've got a board to loan me in the next week or so, I'd use that instead. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]RandR rotation support
I've implemented rotation and reflection support in the core XFree86 server; it was less invasive than I'd feared and seems to work just fine. For most devices, it does it's work by substituting a whole new rendering mechanism based on the shadow frame buffer when the screen is rotated or reflected. Right now, this means that video and DRI won't work right if the screen is rotated; they'll hit the regular frame buffer and mangle things badly. It also permits drivers to support rotation themselves as the siliconmotion hardware seems capable of. It's possible to provide video support in this rotated world; I've implemented that for the Mach64 chipset in Tiny-X (mostly because I could), we could do that for the regular XFree86 servers too with some additional work. On the other hand, DRI probably won't ever work on a rotated screen; you'd have to transmit the rotation information to the application and let them convert transformation matrices and clip lists. That'd be a real adventure. I haven't yet committed the changes to CVS as I'm curious of two things: 1) It hooks into some seemingly silly places -- it needs two initialization steps, one right before acceleration is pushed on top of fb and another right before the software cursor is pushed on top of the acceleration. The first is done by sticking a call inside xf86SetBackingStore, the second by placing a call inside xf86GetPointerScreenFuncs. Those two functions happen to need to be called at precisely the same moment as the RandR hooks, but are obviously not exactly semantically intended for this purpose. The alternative is to require every driver to add calls to RandR, which I'll do if people think it's the right think to do. 2) Permitting rotation incurs an additional layer along several paths inside the X server -- the usual rendering paths all need to get redirected when the system switches from hardware to software rendering, so the screen functions CreateGC, PaintWindow* and the like all get wrapped by the layer module. This new layer is implemented by the 'layer' and 'shadow' modules, both of which must be loaded when the server starts for rotation to ever be possible. It seems reasonable, therefore, that this dynamic rotation mechanism should be selectable. Should I add an option to enable or disable this? Should it be disabled by default? Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Alpha cursors broken on big endian
Around 12 o'clock on Nov 8, Mark Vojkovich wrote: >Running top-of-tree on Linux PPC I'm finding that alpha blended > SW cursors do not seem to work at all. All cursors appear blank. You'll likely have to flip the ARGB data around when sending it to your card -- I've had success reported by people using Radeon cards. WIth redglass lacking any blue component, you'll otherwise get transparent cursors... Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Controlling Render's appetite for dynamic colormap entries
Around 0 o'clock on Nov 7, Olivier Chapuis wrote: > ?? With static class the colors are already defined. It is a 3/3/2 > standard colormap (StaticColor) and you do not have to allocate or free > the colors. There are consecutive the colormap is full (and the > code is perfect first = 0, last = num_entries-1). Actually, StaticColor in fb allocates a 6x6x6 cube and a gray ramp; 3/3/2 is useless for applications. > Fine. So you can have (in theory) first = 0 and last = 255 and render want > to use only 71 entries in the cmap. Now take a look at FindBestColor (it > takes a look at undefined entries). The XFree86 server always places zeros in unallocated entries, so FindBestColor will just skip over those. In any case, the point is moot now because the current implementation doesn't do this anymore because... > Of course this have some (theoretical) importance for QueryPictIndexValues > (In my patch I've assumed that the allocation is consecutive). QueryPictIndexValues doesn't make this assumption anymore. That's what required having the pixel allocation code save all of the pixel values (which is can now use in FindBestColor and FindBestGray). QueryPictIndexValues is quite cheap now; it just copies precomputed data off to the client. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Controlling Render's appetite for dynamic colormap entries
Around 0 o'clock on Nov 7, Olivier Chapuis wrote: > ?? With static class the colors are already defined. It is a 3/3/2 > standard colormap (StaticColor) and you do not have to allocate or free > the colors. There are consecutive the colormap is full (and the > code is perfect first = 0, last = num_entries-1). Actually, StaticColor in fb allocates a 6x6x6 cube and a gray ramp; 3/3/2 is useless for applications. > Fine. So you can have (in theory) first = 0 and last = 255 and render want > to use only 71 entries in the cmap. Now take a look at FindBestColor (it > takes a look at undefined entries). The XFree86 server always places zeros in unallocated entries, so FindBestColor will just skip over those. In any case, the point is moot now because the current implementation doesn't do this anymore because... > Of course this have some (theoretical) importance for QueryPictIndexValues > (In my patch I've assumed that the allocation is consecutive). QueryPictIndexValues doesn't make this assumption anymore. That's what required having the pixel allocation code save all of the pixel values (which is can now use in FindBestColor and FindBestGray). QueryPictIndexValues is quite cheap now; it just copies precomputed data off to the client. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Controlling Render's appetite for dynamic colormap entries
Around 22 o'clock on Nov 6, Olivier Chapuis wrote:
> Maybe ok for some text (but you risk black on black and white one white).
> But take the new cursors, the result is catastrophic.
Some applications may not work optimally on PseudoColor hardware when the
user selects mono mode; it should be no different from running on
monochrome displays. Given that Xft can be configured not to use the
Render extension, it seems like we're providing extra flexibility here by
providing a limited Render extension. I hope few environments require the
'mono' mode.
> I will send a patch soon.
I'm busy hacking your previous patch in; I'm nearly done. It's uncovered
several less than optimal parts of the existing design, so it's not quite
as straightforward as I would have liked.
> But FindBest{Color,Gray} assume that the allocated colors by
> miBuildRenderColormap are consecutive (which is the case in practice).
I don't think so; they work on StaticColor/StaticGray visuals as well for
which no colors are preallocated.
> BTW, it seems strange to have only 13 grey for GrayScale visual
> with 256 cmap entries.
Yeah, caught that today. The color allocation policy now only affects how
colors are allocated out of the default colormap. For visuals other than
the default visual, the whole colormap is used. For pseudo color,
we get a 6x6x6 cube and 46 gray levels. For testing, I added an 'all'
mode and discovered to my delight that Gtk+ and Mozilla were both quite
happy to run with no free colormap cells -- somehow they discovered the
6x6x6 cube and used it. Spooky.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]solution to slow window move/resize problem
Around 15 o'clock on Nov 6, Owen Taylor wrote:
> Last time I talked to Keith about this, he had the idea that perhaps
> when one client configures the window of another client, the priority
> of the second client should be increased.
I've got that patch in my X server right now, and frankly it doesn't help
as much as I'd hoped. I've attached a diff if you'd like to give it a
whirl. If it is useful, I can just stick it into CVS; it's cheap enough.
As you can see, it takes effect when an application configures or maps
another applications window; tracing your window manager will tell you if
this is sufficient, or if additional requests need to be so instrumented.
-keith
Index: dispatch.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/dix/dispatch.c,v
retrieving revision 3.27
diff -u -r3.27 dispatch.c
--- dispatch.c 19 Feb 2002 11:09:21 - 3.27
+++ dispatch.c 26 Jun 2002 17:31:35 -
@@ -344,6 +344,45 @@
}
return best;
}
+
+/*
+ * When a window manager manipulates a client window,
+ * swap scheduling priority between the two so that the
+ * client runs next.
+ */
+void
+SmartScheduleYield (ClientPtr current_client, XID next_rid)
+{
+intnext_index = CLIENT_ID (next_rid);
+ClientPtr next_client;
+
+if (next_index && (next_client = clients[next_index]) &&
+ next_client != current_client)
+{
+ if (current_client->smart_priority > 0)
+ {
+ longbonus = current_client->smart_priority;
+#if 0
+ ErrorF ("0x%x/%d yielding to 0x%x/%d\n",
+ current_client->clientAsMask,
+ current_client->smart_priority,
+ next_client->clientAsMask,
+ next_client->smart_priority);
+#endif
+ current_client->smart_priority = 0;
+ next_client->smart_priority += bonus;
+ if (next_client->smart_priority > SMART_MAX_PRIORITY)
+ next_client->smart_priority = SMART_MAX_PRIORITY;
+ }
+}
+
+}
+#define CHECK_YIELDTO(c,id) (((c)->clientAsMask != ((id) & ~RESOURCE_ID_MASK))?\
+SmartScheduleYield((c),(id)) : (void) 0)
+#endif
+
+#ifndef CHECK_YIELDTO
+#define CHECK_YIELDTO(c,id)
#endif
#define MAJOROP ((xReq *)client->requestBuffer)->reqType
@@ -686,6 +725,7 @@
if (!pWin)
return(BadWindow);
MapWindow(pWin, client);
+CHECK_YIELDTO(client,stuff->id);
/* update cache to say it is mapped */
return(client->noClientException);
}
@@ -759,6 +799,7 @@
return BadLength;
result = ConfigureWindow(pWin, (Mask)stuff->mask, (XID *) &stuff[1],
client);
+CHECK_YIELDTO(client,stuff->window);
if (client->noClientException != Success)
return(client->noClientException);
else
[Xpert]Re: But *why* no vblank?
Around 16 o'clock on Nov 6, Michel =?ISO-8859-1?Q?D=E4nzer?= wrote: > Okay, is there anything wrong with turning the struct for the ioctl into > a union of a request and a reply struct? :) That is the usual way, I believe... Or, you can just build a larger struct containing both pieces. > Yes. The blocking ioctl also returns a timestamp, is that important for > the signal? Might be nice; there's plenty of space. Is it expensive to compute? > Oh, and BTW, is it okay for the ioctl to trigger a single signal, or > would it have to generate signals indefinitely? Might want a mode that chose between these two options, but if I had to pick one, I'd ask for a single signal. That's what SYNC wants. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Controlling Render's appetite for dynamic colormap entries
Around 15 o'clock on Nov 6, Olivier Chapuis wrote: > First why you choose to use 13 grey levels and not 16 grey levels? So that 25%, 50% and 75% were all available. 13 gray levels give: 0.00% 8.33% 16.67% 25.00% 33.33% 41.67% 50.00% 58.33% 66.67% 75.00% 83.33% 91.67% 100.00% 16 gray levels gives: 0.00% 6.67% 13.33% 20.00% 26.67% 33.33% 40.00% 46.67% 53.33% 60.00% 66.67% 73.33% 80.00% 86.67% 93.33% 100.00% > Moreover, with 16 grey levels every thing is contained in the 16x16x16 cc. > > Moreover, 16 seems a better number than 13. 16 = 2^4 (may leads to > various simplification if dithering is implemented one day). These may well both be true, and we can re-evaluate which colors to use in the future if such things become relevant. > Secondly, I do not understand the "mono"/"grey" argument to -render. I > understand "mono"/"grey" when it is the default. However, as an > option with a 256 PseudoColor Cmap I am totally lost ... as a > developer. I used XRender in my programs for displaying text (Xft) > and icons. We have functions which can perform XRender emulation for X > server/driver without render support. Render provides for accelerated and network-efficient client-side text. Even if that text is strictly monochrome, it's still quite useful. Doing the emulation on the client-side will make networked applications significantly slower. > Finally, I send a patch to this mailing list for an implementation of > QueryPictIndexValues (Render proto). Are you interested? I can recheck > it, make the patch against the current cvs I send it to [EMAIL PROTECTED] Oh yeah, I'll go dig that up and apply it. Thanks a bunch. > About this, I've one trouble. It is the first / last Pixel logic in > render/miindex.c. For me in any case at the end first = 0 and > last = "nbr of colors" - 1. No? Why this troubling logic? The colormap allocator isn't required to allocate colors in any particular order; the logic in that function is designed to handle the case where colors are allocated in some random order. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Controlling Render's appetite for dynamic colormap entries
Around 8 o'clock on Nov 5, Xavier Bestel wrote: > I don't want to be a jackass, but why isn't it dynamically settable ? I > mean, each day we discover that config-file options are a pain, because > they prevent dynamic reconfiguration which is a must for a modern > desktop. Hmm. Render doesn't provide any mechanism for notifying clients that the set of pixels used to draw to pseudo color formats has changed. If that were allowed, clients would have to essentially restart themselves to recompute every pixel in every drawable, including pixmaps. Given that few desktops run in pseudo color mode, it's very likely that a substantial number of applications would have latent bugs in this area, so changing the set of render colors wouldn't work very well. Adding this level of complexity for a pixel format which is (finally) disappearing from common use didn't seem worthwhile. The choice is between making the common (TrueColor) case easier to manage (by eliminating any need to even think about writable colormaps) or providing a high level of support for legacy displays (PseudoColor). Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Controlling Render's appetite for dynamic colormap entries
I've implemented a simple configurable mode to control how many colors the Render extension allocates on dynamic indexed visuals (pseudo/gray). Here's the comment I wrote in the code: /* * For dynamic indexed visuals (GrayScale and PseudoColor), these control the * selection of colors allocated for drawing to Pictures. The default * policy depends on the size of the colormap: * * Size Default Policy * * < 64PolicyMono * < 256 PolicyGray * 256 PolicyColor (only on PseudoColor) * * The actual allocation code lives in miindex.c, and so is * austensibly server dependent, but that code does: * * PolicyMono Allocate no additional colors, use black and white * PolicyGray Allocate 13 gray levels (11 cells used) * PolicyColor Allocate a 4x4x4 cube and 13 gray levels (71 cells used) * * Here's a picture to help understand how many colors are * actually allocated (this is just the gray ramp): * * gray level * all 1555 2aaa 4000 6aaa 8000 9555 bfff d555 eaaa * b/w * 4x4x4 * extra 1555 2aaa 4000 6aaa 8000 9555 bfff d555 eaaa * * The default colormap supplies two gray levels (black/white), the * 4x4x4 cube allocates another two and nine more are allocated to fill * in the 13 levels. When the 4x4x4 cube is not allocated, a total of * 11 cells are allocated. */ This policy is controlled by either a command line option (-render) or an XF86Config parameter that lives in the ServerFlags section: Section "ServerFlags" Option "RenderColormapMode""gray" EndSection The set of modes is the same in both cases 'default', 'mono', 'gray' and 'color'. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: But *why* no vblank?
Around 15 o'clock on Nov 3, Michel =?ISO-8859-1?Q?D=E4nzer?= wrote: > Oh, and are there any opinions about the signal to use, SIGALRM or > something else? You'll have to make it settable -- SIGALRM is already used by the X server for scheduling. Of course, we could eliminate that if I could get the current time of day mapped into the X server address space :-) > > * The interface needs to provide a vblank counter, so the user can easily > > detect dropped vblanks. > > Has been there from day 1. I wonder what to do about this for the signal > though, put the sequence number into the siginfo (is that possible?), or > is the information you get back from the ioctl enough? It would be nice to get it without another syscall; there's certainly enough space in the siginfo to pass it along. I assume you'd pass along the current counter value and not some kind of delta. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]More on the new cursor
Around 21 o'clock on Oct 30, oliver wrote: > So if i get things right by reading these couple posts, it means that > this pretty ARGB cursor I'm getting is software based. The Radeon driver now has HW support for ARGB cursors; the nVidia driver should have support shortly. Adding support to other cards that have appropriate hardware will be easy for someone with the hardware and the docs. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
Around 15 o'clock on Nov 1, Mark Vojkovich wrote: > What? Did you just say you're going to delay flushing the data > to the server until some time after the retrace happens (there's > a significant latency there) and you think the X-server is actually > going to execute that almost immediately? No, that would be crazy. The SYNC extension permits the client to deliver a batch of requests headed by a SYNC request which blocks that client until the specified condition is met. That client is then immediately restarted and the queued requests are executed. Getting from a signal to the driver should be a matter of moments at that point -- no context switch is required, and no additional I/O operations are necessary. It does sort of require that the X server be scheduled when the signal is delivered, but that can be done relatively easily inside the kernel. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
Around 15 o'clock on Nov 1, Mark Vojkovich wrote: > > How about a signal when vertical blanking arrives? (1st choice) That, or > > something we can select on? (2nd choice) > > What are you trying to solve? The problem of syncing XCopyArea > to the retrace? If so, how does this lead to a solution? Hook the signal up to an XSYNC counter, block the client on the counter with the XCopyArea request sitting in the request buffer. Signal fires, the client is scheduled and the CopyArea executes. For an idle X server, we should have sub-ms latency, which is sufficient for this particular task. Active X servers will have to terminate any executing request, but the signal will force an immediate reschedule so the latency will grow only by the time it takes to execute that request. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]stopping screen blanks
On Tue, 29 Oct 2002 [EMAIL PROTECTED] wrote: > How can I stop X from blanking the screen after a period of inactivity? I have > a laptop with a builtin mouse and keyboard, and an external USB mouse. When I > use the external mouse, it doesn't count it as being "activity", so I'll be in > the middle of browsing a web page and the screen will blank. Sounds like your BIOS is misconfigured. Laptops BIOS settings often include idle blanking; disable that and you should be fine. You may have to run the other OS to configure the BIOS as many laptops don't have sufficient control from the setup menus. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Colour Cursors.
Around 23 o'clock on Oct 25, James Hawtin wrote: > Errr how do I turn them off and go back to the old ones, I find the new > xterm (default text entry one) particularly bad, using default fonts its 2 > lines high one character wide and shaped like a red dog bone, the shadow > is annoying in this case as well. Xcursor is configurable via environment variables and X resources. It should probably have a dot file too, just to keep up with other Unix utilities. (resource/environment variable): type... Xcursor.core/XCURSOR_CORE bool Whether to use core cursors exclusively, overriding any available Render extension capability. Xcursor.size/XCURSOR_SIZE int Nominal size for cursors. Themed cursors can have multiple sizes for each cursor, Xcursor picks the size closest to this size from those available. If Xcursor adds SVG support, this size will be used to scale the SVG objects. Xft.dpi int If Xcursor.size isn't set, then this value is used to compute the nominal size = dpi * 16 / 72 Xcursor.theme/XCURSOR_THEME string Name of theme. Xcursor uses the freedesktop.org icon theme specification to locate cursor files; cursors live in one of the icon directories in a cursors subdirectory. Xcursor looks in the standard icon directories, along with /usr/X11R6/lib/X11/icons. It also parses the index.theme file to follow Inherits values. If no theme is set, Xcursor uses 'default' Xcursor.dither/XCURSOR_DITHER threshold/median/ordered/diffuse Dithering algorithm when creating core cursors. Xcursor transforms an ARGB cursor into a two color cursor with one of these algorithms (yes, only ordered and diffuse are really dithers). The default is ordered, which is a 2x2 ordered dither. Xcursor.theme_core/XCURSOR_THEME_CORE If the server doesn't support ARGB cursors, this value controls whether Xcursor goes ahead and themes core cursors using the core cursor requests. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]colour mouse cursor
Around 20 o'clock on Oct 25, Juliusz Chroboczek wrote: > KP> If you're running current XFree86 CVS, you should be seeing ARGB cursors > KP> all over your screen as Xlib has been hacked to use them in place of the > KP> stock cursor images. > > XCreateFontCursor ? Can that behaviour be disabled ? Yes, XCreateFontCursor gets redirected to themable cursors now. You can disable this by setting the Xcursor.theme_core resource or the XCURSOR_THEME_CORE environment variable to 'false'. > Are monochrome cursors with no non-integer alpha values automatically > converted into hardware cursors ? No, but that's a pretty good idea. Should be easy to do as the code already walks the image converting it from ARGB to a core cursor so that hardware can be used when necessary; right now, the core cursor is created by dithering against black and white which isn't quite what you want. > If so, at what level does that happen ? Core cursor compatibility happens inside the X server and inside the Xcursor library. Core theming is disabled by default unless the server supports ARGB cursors. > I'm sorry for the silly questions, but I'm a little late w.r.t. CVS > right now. Silly questions take less time to answer :-) Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Imake.tmpl uses BuildLibraries before it's defined
BuildLibraries is defined in X11.tmpl, but Imake.tmpl uses it to define LdPreLib before X11.tmpl is included. The result is that every Imakefile using LdPreLib will end up using an incorrect definition. This is usually harmless on native builds, but breaks cross compilation badly and may cause problems when building X on a machine with a significantly older version installed. It's not easy to fix though. X11.rules uses LdPreLib in defining LdPreLibs, and X11.rules is included before X11.tmpl. Here's what I've done: 1) Removed dependency on BuildLibraries for LdPreLib, LdPreLib now refers only to -L$(BUILDLIBDIR) or -L$(USRLIBDIR) depending on UseInstalled and AlternateUsrLibDir. This means that LdPreLib never contains -L$(USRLIBDIR) unless UseInstalled is set to YES 2) Created a new make variable 'INSTALLED_LIBS' parallel to 'INSTALLED_INCLUDES' which points at the installed libraries if any of them might be useful. This gets set to -L$(USRLIBDIR) when !defined(UseInstalled) && !BuildLibraries && AlternateUsrLibDir. Otherwise it's left as NULL. 3) Add $(INSTALLED_LIBS) to LDPRELIB and LDPRELIBS values. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]colour mouse cursor
Around 10 o'clock on Oct 25, Dr Andrew C Aitchison wrote: > Is anything other than 8+24 overlay mode still using cfb ? No, and it shouldn't be a huge amount of work to fix this problem either. Then we could stop building cfb and mfb. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]colour mouse cursor
Around 16 o'clock on Oct 24, "J. Imlay" wrote: > If I understand things correctly the hardware cursor suported > in XAA is 2bit, so you can't have true color cursors. Is this going to > change with this extension? Or I am wrong and you can have colored cursors > in X? XFree86 already has a software fallback mechanism for cursors which aren't supported by the hardware. ARGB cursors are just kind of cursor which XFree86 passes back to the software layer. At some point, the driver interface can be expanded to expose these cursors to the underlying software for hardware which does support these kinds of cursors. If you're running current XFree86 CVS, you should be seeing ARGB cursors all over your screen as Xlib has been hacked to use them in place of the stock cursor images. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]colour mouse cursor
Around 16 o'clock on Oct 24, Dr Andrew C Aitchison wrote: > I don't know the recipe to tell it to use a different cursor, but > xcursorgen can build animated cursors from image files The extension doesn't (currently) support animated cursors, I'm waiting for someone to try and build them into a toolkit so we can get an idea of how this should work, and how much server-side support is really necessary or desirable. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: 8-bit pseudocolur emulation on direct color hardware
Around 10 o'clock on Oct 23, Dr Andrew C Aitchison wrote: > I'd like to do this. > Where abouts would it go in - > I guess that this would be another directory alongside > programs/Xserver/hw/xfree86/xf24_32bp > and > programs/Xserver/hw/xfree86/xf8_32bpp ? As this module should be independent of the XFree86 driver interfaces, it should live in Xserver/miext instead, alongside the shadow frame buffer code. > Where should I look to generate the list of functions which would need to > be implemented ? The usual suspects can be found in any rendering wrapping module; software cursors, backing store and shadow frame buffer are three such examples. > Are we just going for 8bit pseudocolor on 24 bit directcolor, > or is it worth trying 5bit pseudo on 15/16 bit directcolour too ? I'm not sure 5-bit is interesting; many legacy apps assume 256 writable colormap entries or they'd work with a 5x5x5 cube preallocated by Render. > Can anyone point me at instructions for testing an X server, > once I thing I have it working ? I know about I've just updated the Makefile for building the X test suite documentation; that's found in the test module (test/xsuite/xtest/doc). Perhaps those would be of interest? In particular, the 'pt -i' command runs a single test from the current directory (one of xsuite/xtest/tset/*/*). Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Colormap Allocation problems under Linux 7.3
Around 9 o'clock on Oct 23, Olivier Chapuis wrote: > An application should query if the xserver has render support and if not > take appropriate decisions. No? E.g., in FVWM we have a function which > simulate XRenderComposite and a font spec can have two fonts one for Xft > and an other one for core text rendering. Client-side text is a powerful mechanism which is not easily replaced with core fonts. Xft uses the core protocol GetImage/PutImage when Render is not available, but performance suffers greatly. Applications like OpenOffice (and FrameMaker) are unable to provide reasonable text output with the core font primitives. Client-side text is useful independently from anti-aliasing. > In some case it is not the number of colors which counts but how the > apps share the colours. Our working assumption is that 8-bit PseudoColor displays are useful only for legacy applications; those don't generally share well with others as they need custom or writable color values. Any significant number of preallocated color cells generally cause these applications to fail. > Moreover, if you use standard dithering methods, dithering is really really > better in mode #5 and #6 than in the default mode. So I think that Render doesn't (currently) support dithering, and dithering to a random set of colors is rather expensive. I like having both a color cube and a gray ramp as I believe that provides more accurate anti-aliased text, I'm not sure how dithering fits into this model. > Yes, using StaticColor is more or less equivalent than mode #6 (but > with a bit different colours proportion (3/3/2) by default). The new fb frame buffer code fits the largest color cube and fills the remaining entries with a gray ramp, precisely as you've described for mode #6. PseudoColor with a completely allocated colormap is a poor substitute -- with StaticColor, the server will automatically fit new color requests into the existing color entries, while PseudoColor will fail the allocation request. > I think a "full" mode does not hurt and assure backward compatibility. > But, I do not care. I am more interested by mode #5. Any PseudoColor mode which doesn't permit the bulk of legacy applications to run without problems isn't interesting in this context; it may be that the 'default' mode can allocate a few more colors than it does in current CVS, but I don't think it should use a 5x5x5 cube > An other subject. Do you think that it is better to always use > pow(2,k) grey colours (e.g., use 16 grey for the default in the place > of the 21 grey) so that the grey are aligned with the 32x32x32 colour > cube which is used to "approximate" the render colors? That's a good idea; we could actually eliminate the entries in the gray ramp duplicated within the color cube. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Colormap Allocation problems under Linux 7.3
Around 23 o'clock on Oct 22, David Dawes wrote: > If it can be run in a mode where no colours other than black or white are > allocated, then that'd be OK. It needs to be possible to have a > configuration where legacy pseudocolor-only clients can run without > interference. I can't think of too many reasons why people would choose to > run in 8-bit mode other than to be able to run such clients. Someone should implement 8-bit emulation on direct color hardware. Glue that together with hacks to fake out the root visual and we'd eliminate this kind of foolishness. But, it's also of less and less interest as these apps fade into obscurity. > That sounds reasonable to me. It also simplifies the implementation > (unless we want to be able to set these options per-screen from > the config file). I guess it hardly matters. Assuming that 8-bit is used strictly for broken apps, then any sensible person wouldn't want to have one 8-bit screen for legacy apps and another 8-bit screen for current apps -- they'd run the second screen at 24 bits. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Colormap Allocation problems under Linux 7.3
Around 22 o'clock on Oct 22, David Dawes wrote: > > -no-render-extension / NoRenderExtension > > -render-extension (for cancelling a NoRenderExtension option in > > XF86Config) Might shorten these to '-norender' and '-render'. However, I'd argue that Render should be considered a "core" extension and not be made optional at all. Applications like OpenOffice and Mozilla will not function reasonably without it, and (see below), it's impact can be mitigated or even eliminated, although some apps will probably produce "unexpected" results without any render colors in the default colormap aside from black and white. I note that we don't have a '-noshape' option available. > >clGreyScale PseudoColor > > > >0 : default default > >1 : 8 grey 8 grey > >2 : 16 grey 2x2x2 cc + 4 grey (or 8?) > >3 : 32 grey 3x3x3 cc + 8 grey (or 16?) > >4 : 64 grey 4x4x4 cc + 16 grey (or 23?) > >5 : 128 grey5x5x5 cc + 16 grey (or 32?) > >6 : 256 grey6x6x6 cc + 32 grey (or 30) > > > > -render-color-limit (int)cl / RenderColorLimit (int)cl This seems more like a mode to me, and it seems like fewer choices would be better. Certainly mode #6 is not useful as it's identical to a static colormap, except that the server won't do any nearest color matching. I suggest three models would be sufficient: -render-colors none - render uses only BlackPixel and WhitePixel -render-colors few - render gets 16(?) levels of gray -render-colors default - render gets a modest number as in current CVS 'few' mode will still be very useful in displaying AA text while consuming only a small part of the colormap, while 'none' eliminates any impact on the colormap while still permitting applications to accelerate non-AA client-side text. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 CVS and 1600x1024 (DVI) / Radeon
Around 10 o'clock on Oct 18, Jeff Brubaker wrote: > Unfortunately, X comes up with a root window size of 1600x1024 (reported by > xdpyinfo) but is really only outputting 1280x1024 (reported by my SGI > MultiLink adapter). Hmm. The Radeon driver mode selection code was restructured during the RandR integration, it's quite possible that some mode lines aren't getting properly added. But, your log file seems to list 1600x1024 as a valid mode, so I'm a bit confused. What does 'xrandr' list as valid sizes? > Any ideas? I also noticed that xrandr died with BadParameter errors for > anything other than changing the screen resolution. I'm guessing the ATI > driver needs updating to handle the new extension. The current RandR support in the core server is limited to size changes; rotation and reflection would have entailed some more invasive changes to the acceleration code that seemed inappropriate at this point in the release cycle. > Oh, and just to put every question in a single e-mail, even in 24bpp, pixmaps > appear to be 16bpp. The log you enclosed showed the screen running at 16bpp; I assume setting the depth to 24 switches that to 32bpp? Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Time-machine messages
Around 1 o'clock on Oct 9, Kacper Wysocki wrote: > Does anyone have a reasonable explenation for why I just received a > huge amount of Xpert digests, all with correct sequential no's, that > are full of messages dated August? I've finally managed to unblock the messages queued for spam filtering. Mailman uses a web interface to filter mail and only with version 1.2b of Mozilla have I found a browser capable of displaying a page containing the list of nearly 1000 queued messages. Things should get back to normal now. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]RandR and radeon
Around 19 o'clock on Aug 26, John Lenton wrote: > Now, asking around, it turns out that nope, and probably not before > whatever comes after 4.3. However, I also understand that the rotate part > is the hard one, and all I'm interested is being able to change the size of > the screen, so I can run xdm at a size my wife can read the letters but > still log in to an emacs I can program with :) Support for the resize portion of RandR is in current XFree86 CVS and works on all XFree86 drivers. This support doesn't rerun DDC or EDID so that switching monitors won't give the desired results, but at least you can resize the screen to modes supported by the original monitor. Reprobing and rotation support are available in the kdrive vesa server and serve to demonstrate those portions of the extension. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]CursorBits.argb premultiplied?
Around 22 o'clock on Aug 29, [EMAIL PROTECTED] wrote: > One question: in the CursorBits.argb data, has the color data already been > premultiplied by the alpha, or not? Yes, Render always uses premultiplied data. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XML format for XF86Config
Around 14 o'clock on Oct 3, Michael Michael wrote: > The big picture is I'd like to move towards a XML format for flat file view > and database for ui managers. Moving to XML helps a lot in moving on to a > system wide config data base. A zillion config file formats makes it > difficult to contemplate. If everyone would move to and XML format then > supporting config databases becomes possible. It doesn't take everyone moving to make this a useful idea; even moving a few systems to a common configuration language would help reduce the problem, and new systems could then see a clear direction in configuration file support. However, you're not going to get any help in this quest until you've generated a concensus among the community that this is a good and useful idea. That can only be done by providing sample implementations that fit neatly into significant existing systems. It's not that each project is lazy or stupid, it's that the work necessary to actually realize any utility is greater than any individual project can support within the framework of the project itself. > I would like to see happen in the unix world. It does require each major > subsystem developer to look beyond there needs. Considering most of the > responses so far I'm not sure thats going to be easy. If it were easy, we'd already be doing it. I'm all for XML-based configuration files (ref fontconfig), but I'm also realistic about the installed base of X configuration files and the existing community expertise in managing them. You can't throw that away lightly, instead you'll have to replace that with a more compelling solution. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Autoconfiguring
Around 13 o'clock on Oct 1, Billy Biggs wrote: > Can you successfully add modes yet? In december I was unable to (but > I patched the vidmode extension code to have it work, sorry I didn't > send that patch in yet). Did someone else fix it? I don't know; I didn't test or change any of that code. If you've got a fix that makes it work, please send it along with a sample program to actually test this stuff. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Autoconfiguring
Around 9 o'clock on Oct 1, Dr Andrew C Aitchison wrote: > use XFree86-VidModeExtension to change the video timings on the fly. From > this week you could even use the RandR extension to change the virtual > desktop size if appropriate. Yes, RandR will pick up screen sizes from any video modes added through the VidMode extension. RandR also permits DDX to reprobe the monitor whenever the app requests the available sizes. The kdrive-based Xvesa server requeries the BIOS at this point to catch monitor changes. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XML format for XF86Config
My hope is that the configuration file becomes entirely optional. There's essentially nothing there which can't be autodetected on a reasonable system. At that point, the format of the file is moot. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]RandR and per-user config
Around 6 o'clock on Sep 30, Alex Deucher wrote: > Now that X RandR support has gone into CVS, I was wondering if it might > be possible to add an option to allow each user to specify a separate > resolution or color depth, so that when they logged in via xdm/gdm/kdm > the screen resolution would change appropriately. maybe some option in > their .xinitrc. You can't change the depth, but you can change the size with the 'xrandr' program. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Resize and Rotate extension progress report
Around 9 o'clock on Sep 24, Steve Kirkendall wrote: > What's the motivation for implementing the emulated visuals in the > server? Do some video cards have special hardware for doing the > conversion? It's a bit more efficient to do the emulation in the server; a client-side emulation would require the pseudo->true conversion be done to a temporary image and then the results sent to the server for display. That's an extra copy of the data. It also provides a more consistent environment for applications. If the X server emulates 8, 16 and 24 bit visuals then migrating applications between servers is significantly easier and doesn't require negotiating which proxy the application should connect to. > Because otherwise, I'd say the PseudoColor emulation should be done > in the Xnest-like proxy. That way, the real XFree86 server stays > simpler and the proxy can be used with any X server. The problem with Xnest is that it provides a whole window system inside a single window; useful for some debugging situations, but it doesn't integrate the two window hierarchies. There's no cut&paste between Xnest apps and regular apps and you've got two window managers running. I think you could probably write a proxy that mapped windows straight across, but it would be quite a bit of work to get the semantics straight when applications communicatee across the proxy boundary. Doing the emulation inside the X server is actually quite easy, the hard part that RandR added was the ability to switch which visuals were emulated and which were mapped directly to the hardware. The current server internals are not structured well to handle that case. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Resize and Rotate extension progress report
Around 19 o'clock on Sep 23, Andy Isaacson wrote: > I just plain don't understand why PseudoColor emulation has to be so > expensive. Can't you just do it in the same manner as the ShadowFB > layer, whereby the screen representation is updated only every 10 ms or > whatever? Yes, that's the usual implementation (although there are others). The problem is applications expect that updates to the colormap are cheap, but sending the entire frame buffer over the AGP bus is quite expensive, as you say, optimizations are possible, but it takes some clever code to take advantage of any kind of pipelining on the AGP bus while skipping the large unmodified parts of the screen. One thought I just had was that Xlib/Xnest style hacks could give every client a private colormap. This would limit the damage to that clients windows instead of forcing a scan of the whole screen. The RandR question remains though -- if this approach is sufficient to resolve the needs of 80% of the clients, is the ability to swap which visuals are mapped directly to the hardware interesting enough to spend significant effort on in the near future? Or should we just leave RandR as the resize/rotate extension and leave hardware visual swaps for some future extension if we ever need it ? Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Resize and Rotate extension progress report
Around 16 o'clock on Sep 23, David Dawes wrote: > I always wondered why depth switching was part of the RandR extension. The original idea was that size and depth would have to be switched simultaneously to fit video card memory constraints. > I think that RandR should do what it's name suggests: resize and rotate, > and the various depth switching and visual emulation problems/features > be handled separately. Visual emulation is separate from RandR, and has been implemented a couple of times already. Given that visual emulation is a good idea in some environments, is it also a good idea to be able to change which visuals are expressed in the hardware configuration? PseudoColor emulation on TrueColor is pretty expensive when applications start performing colormap animation tricks. RandR attempts to resolve this by allowing the mapping between sets of visuals and the hardware to change on the fly. It's by far the most complicated part of the spec, and would require visual emulation code plus the ability to switch the hardware configuration around. That's a bunch of work that we're not going to be able to do anytime soon, without a sample implementation, we risk adopting an unworkable standard, a fate much worse than not adopting any standard. I think we can be careful enough with the existing spec that depth switching could be folded in if needed in the future. > > a chance to plug the necessary > >hooks into the regular XFree86 server to support resize immediately. > > That's definitely what is needed for RandR to be useful to most of this > audience. The daunting task of providing an SI for depth switching held up the decision to move forward with resize. Size switching should be relatively easy given the internal structure of XFree86. Drivers using XAA may even be able to provide rotation, although I haven't investigated that very far. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Resize and Rotate extension progress report
Around 11 o'clock on Sep 23, Steve Kirkendall wrote: > I think the best way to handle this would be to put the PseudoColor > emulation code into something like Xnest -- a server which merely passes > the requests on to a real X server after translating the colors. The > legacy applications would run on the Xnest-like display, while modern > applications talk directly to the real X server. That's probably a reasonable approach for switching which visual is the default. Couple that with server-side support for emulated visuals and you've got a pretty complete solution. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Resize and Rotate extension progress report
Around 12 o'clock on Sep 21, Dr Andrew C Aitchison wrote: > Although 8+24 overlay hardware support is very limited, PC hardware support > for DirectColor isn't uncommon. I take it you intend to emulate PsuedoColor > when DirectColor is available ? (Color-map flashing can be annoying, so I > wouldn't object to a server flag which had to be set to enable PsuedoColor > emulation.) Visual emulation is a requirement for RandR depth switching, but not vice-versa. RandR extends visual emulation by allowing the selection of which visuals should be accelerated, essentially the hardware is reprogrammed on the fly to select the desired acceleration mode and applications using other visuals get emulated. We've got samples of emulating PseudoColor visuals on TrueColor hardware and it's easy to see how you would emulate PseudoColor on DirectColor hardware. We don't have an example of emulating 24-bit TrueColor on an 8-bit pseudo color visual, but with Render, at least the appearance is well defined. The part that's hard is in switching which depth is accelerated and migrating windows between the real frame buffer and off-screen virtual frame buffers. The current X server architecture makes that problematic as there are many datastructures which embed knowledge of screen characteristics. So, we can move forward with visual emulation to provide PseudoColor visuals on True (or Direct) color screens. What Jim suggests is that we (at least temporarily) give up on the idea of switching the hardware around to match the currently active application. > "Rotate and Resize" doesn't imply "Redepth", so I can't really object, > but my interest in RandR has always been in the possibility of running > legacy 8 bit apps on a 24 bit screen. RandR doesn't have any (direct) impact on that. Just providing an 8-bit visual to provide PseudoColor for old apps is easy (if a bit slow). The trick is reprogramming the hardware and fixing up all of the server internal datastructures. Another important point -- legacy apps often assume that the 8-bit visual is the default. RandR doesn't address this issue at all; the default visual is not effectively switchable so RandR leaves the default visual alone making legacy apps suffer if it is not what they expect. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Resize and Rotate extension progress report
Around 1 o'clock on Sep 20, Alexander Stohr wrote: > I mean is there anything aside to what is already > existing as code? Documentation? Samples? HowTo's? > Or even a web site that covers the topic and the idea? Why don't you see if http://www.xfree86.org/~keithp/talks/randr/ has what you want. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Resize and Rotate extension progress report
The Resize and Rotate extension allows the root window to change size and rotation while the server is running and to switch the hardware among various depths. A preliminary implementation of this extension is included with current XFree86 bits, but only the kdrive-based X servers have ever implemented the necessary server-side pieces (for rotation and resize, but not for depth switching). Jim Gettys has been busily working on the device-independent and library portions of the Resize and Rotate extension for the last month and has completed it, and we're both hoping to get a chance to plug the necessary hooks into the regular XFree86 server to support resize immediately. A question has arisen recently and we're hoping for some outside comments, given the passage of time and somewhat unanticipated advances in modern toolkits. The current RandR spec takes advantage of the ability for X to advertise multiple visuals on each screen to try and switch the depth of the screen. This is done by having the server advertise all possible visuals and depths in the server at startup time and then having RandR switch which visuals are "accelerated" and which were presumably emulated in software. The idea was to make sure that existing application would still be usable while the screen depth was switched -- emulating the desired visual with the hardware would leave those "legacy" applications running in an emulated visual while the "smart" applications reconfigured themselves to use one of the currently accelerated visuals. This is the one part of RandR which doesn't currently have a sample implementation, and the the part of RandR which will require the most extensive modifications within the X server. Given that there is no sample implementation of this capability, and that at least Jim and I aren't going to manage to produce one in the immediate future, the question is should we eliminate this part of the RandR specification so that the extension as a whole can demonstrate a complete sample implementation and become a useful standard part of XFree86? Eliminating this feature from RandR would mean that applications migrating from one X screen to another would need to be able to adapt to the available visuals, rather than anticipating that whatever visual currently in use would be available in the target server. As both Gtk+ 2 and Qt provide very abstract rendering interfaces for applications, (and GTK 2.2 supports moving between screens even between dissimilar X servers) this is not a burden for migrating applications written to either of these two toolkits, reducing the urgency of this part of the extension. The burden would fall solely on legacy toolkit applications which want to add migration capabilities (and the number of legacy toolkit applications continue to decline). The other limitation would be that there would be no good way to share typical PC hardware between pseudo color and true color applications. Emulating pseuedo color operations on true color screens remains impractical. Environments left with legacy pseudo-color dependent apps would continue to run X servers in pseudo color mode without access to reasonable true color visuals. We could still perform this emulation in the server, but RandR provided the means to switch acceleration modes so that a large pseudo color app could get reasonable performance while wrecking the display of any simultaneously displayed true color apps. However, without some interest in the community for this feature along with a reasonable commitment to helping with the implementation, it seems more important to get the subset of the specification known to work deployed widely rather than wait an indeterminant time for this final piece of the original design to be completed. Please comment if you have an opinion. Keith Packard XFree86 Core Team Cambridge Research Lab, HPLabs, HP Jim GettysCambridge Research Lab, HPLabs, HP ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]TSLIB and TinyX
Around 18 o'clock on Sep 6, Michael Taht wrote: > But, conceptually, to me, having button 1 down when you touch the screen > in an arbitrary place should "just work". Or should it always pretend it > delta'd in from another place so that entering/leaving areas works? Yeah, you have to send a motion event before you can send the button event. That's just the way the server works. It ignores position in button events. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]what's exact meaning of request length
Around 10 o'clock on Sep 4, Mark Vojkovich wrote: >The size of the structure is implied by the reqType. Length > is the number of 4-byte chunks beyond the structure that belong to this > request. Length includes the basic request structure in requests as they are variable length, but the reply length indicates the number of additional 4-byte values beyond the 32-byte fixed-size reply header. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Problems with XClock from CVS
Around 23 o'clock on Aug 26, James A. Crippen wrote: > The clock itself still functions fine, but it's as though the > background part of the XClock window isn't receiving exposure events, > and that it's not accepting the font resource or Xt font command line. Xclock now uses the Render extension in analog and digital modes. There was a bug in exposure handling in digital mode which made the background not get cleared. Oops. I'm a bit surprised I didn't catch that during development, but I didn't and you did. If you have a recent X server (CVS), I think you'll find the analog mode quite entertaining. To change fonts in Render mode, use the '-fa' flag instead of '-fn'. To get your old xclock back, use the '-norender' flag. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Savage4 Specs (Was: Support for S3 Savage4 in 4.2.0)
Around 12 o'clock on Aug 21, =?iso-8859-1?Q?Jos=E9?= Fonseca wrote: > Keith, I assume that you have received permission to redistribute these > documents. Do you think that the BCI tech ref could be also > redistributable? (Max Lingua already has that one). I really don't recall where those documents came from; it was long before I joined the XFree86 project, so I'm sure I didn't sign any kind of NDA for them. Given what I now know about S3's policy, I suspect they were inappropriately redistributed at the time, so I've made them inaccessible again. I'd forgotten they were on my web site. Too much disk space can be a dangerous thing. I was under the impression that XFree86 had an NDA with S3 covering this documentation. If so, you need only apply for "membership" in XFree86. "Membership" is a formal relationship with XFree86 which permits the redistribution of material covered by various old NDAs that XFree86 used to have with hardware manufacturers; most current vendors use other methods to keep their designs private. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Reply code
Around 11 o'clock on Aug 13, Mark Vojkovich wrote: >Replys are synchronous. The reply goes with whatever request > was before it. There is no need for reply codes. In particular, within Xlib, replies are matched with requests by sequence number. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]problem with Xft and pango
Around 14 o'clock on Aug 3, Fred Heitkamp wrote: > I'm trying to compile the latest CVS pango version. > Is this possible? Yes, but you need to make sure you've added the FreeType2 header directory to the include path so that you get FreeType2 headers instead of FreeType1. the xft.pc file installed with current XFree86 CVS Xft2 should point at the right headers. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XftConfig is ignored
Around 22 o'clock on Jul 28, Paul Hoepfner-Homme wrote: > I can't enable sub-pixel antialiasing with my Radeon card in XFree86 4.2.0 > (actually the DRI CVS branch) I don't know about the DRI CVS branch, but current XFree86 CVS doesn't use XftConfig anylonger. Check to see if you have /etc/fonts/fonts.conf, that would indicate you're using fontconfig now. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Re: Xpert digest, Vol 1 #2013 - 11 msgs
Around 17 o'clock on Jul 25, "Rob Taylor" wrote: >What needs to be implemented for Resize to work? I have a few spare cycles i > could donate... (I'm read most of the server code base at one point or other and > submitted patches before (tho i'm still waiting to hear from a developer on > those...)) As a first hack, all that's really needed is to hook the RandR reconfiguration function up to the existing size switching code in the XFree86 DDX. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]nplanes >=32 ? Can we do 64bit arithmetic ?
Around 7 o'clock on Jul 22, Dr Andrew C Aitchison wrote: > I guess I can put in a comment and assume that d>32 requires major > reworking on the server. The core protocol limits depth to 32 bits and that limit is reflected rather pervasively throughout the server code. Any extension to allow deeper pixels would have to hide the additional bits from the core protocol. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Is this a bug? render/picture.c line 228 and 233, PictureCreateDe faultFormats
Around 17 o'clock on Jul 17, Johannes Rath wrote: > > format = PICT_FORMAT (bpp, PICT_TYPE_COLOR, v, 0, 0, 0); > > I do not understand in the first place is why v (simply a loop index) is > used as an parameter for PICT_FORMAT(). The visual index is passed from this line down to the creation of the format stored in this value, so it's not (actually) a typo, but it is a misuse of the macro. Instead, a different PICT_FORMAT macro should be created for PICT_TYPE_COLOR/PICT_TYPE_GRAY which can hold the entire visual index, even if the server has more than 16 visuals. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]lack of 32bpp mode for G450?
Around 16 o'clock on Jul 9, Dr Andrew C Aitchison wrote: > Setting defaultfbbpp to 24 will save video memory without losing colors, > but it may be slower (or it may not). The matrox 2D hardware accelerates all 24bpp accesses; it's generally faster than 32bpp as a result. However, the 3D hardware doesn't deal with 32bpp frame buffers, so if you want to run the DRI, you'll have to pick either 32bpp or 16bpp (iirc). Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xawtv issues with 24bpp matrox x session
Ed Sweetman wrote: > since the mga driver for the Matrox G450 doesn't support > 32bpp and thus doesn't support alpha layers I was wondering if this is > possible at all to see (XRender's alpha blending and such) Render permits the use of external alpha buffers for visuals which don't include embedded alpha. To include an embedded alpha channel, the server would need to advertise depth 32 windows with RGB masks set to leave 8 bits for alpha. As far as I know, no-one has made the necessary changes to add depth 32 support to XFree86 X servers. The pixel format (bpp) is irrelevant here, aside from needing to be no smaller than depth. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]kdrive screen frequency
Around 16 o'clock on Jul 5, Rolland Dudemaine wrote: > My eyes are crying for a 75 or 85 Hz screen with Kdrive server... > I have successfully launched Xfbdev and Xvesa servers, but the frequency > always remains 72Hz. Changing the arguments on the command line does not > change anything. Neither Xfbdev nor Xvesa have any way to change the refresh rate. Xfbdev relies on the kernel to have already set the appropriate video mode while Xvesa uses the bios in the video card to set the mode. The video card bios mode selection only lists the pixel size and format of the resulting image, not the refresh rate. If you have programming information for your video card, it's quite possible to hack up a custom server that can change the pixel clock after the server has initialized the card. I've done that in the Xtrident server which is based on Xvesa. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]PATCH: X-Video support for Radeon 8500
Around 10 o'clock on Jul 2, Keith Whitwell wrote: > It's hard to do testing for the mobility cards without access to one... No kidding. I finally went out and bought an 8500 to get video working on that. Between Kevin and myself, we were able to test pretty much every Radeon. > However, I've found a couple of obvious gotcha's in the recent code that > can be cleared out -- we are still emitting some tcl state even on mobility > cards which would certainly be causing some problems. Sounds like Radeon DRI support is rapidly stablizing. I'd like to get the XFree86 tree working again at some point, but it's diverged quite a ways from the DRI at this point with a bunch of multi-head patches from ATI. XFree86 will be doing a release sometime this year; if the DRI bits are going to be stable in the next couple of months, it would be nice to get them integrated so they could have wider testing for a while before the XFree86 release. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]PATCH: X-Video support for Radeon 8500
Around 17 o'clock on Jul 1, James Ralston wrote: > So, it would appear that 3D support for the Radeon 64 DDR and the > Radeon Mobility M6 LY (and I suspect all Radeons) was accidentally > broken in CVS sometime on or before 2002-06-23. It's been broken for me on my M6 LY ever since Mesa 4 hit XFree86 CVS shortly after 4.2. I use the DRI tcl-0-0 branch on my 7500, but that wasn't working on my M6 when I last tried it a month or so ago. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Support for more mouse buttons?
Around 13 o'clock on Jun 29, Alan Coopersmith wrote: > > At one point I got the impression that XFree86 didn't support more > > than five buttons. Is this true? This would seem to me like an > > arbitrary limit that we should grow past nowadays... No. The core protocol supports up to 256 (255?) buttons. > The limitation on core pointer buttons comes from the event definition in the > core X11 protocol: > > SETofKEYBUTMASK That limit restricts which mouse buttons are present in the state field for events and which may be used to modify grabs, it doesn't restrict the reporting of higher numbered mouse buttons in regular button events, nor grabbing those buttons. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]PATCH: X-Video support for Radeon 8500
Around 18 o'clock on Jun 24, James Ralston wrote: > I've been trying to get X-Video support working for the Radeon 8500. > > Although there were some changes made to the Radeon driver in CVS > early this month, as of a 2002-06-23 CVS checkout, X-Video support > still doesn't work: applications that try to use it just display a > black area. I grabbed your patch and it applied cleanly to current XFree86 CVS, but broke video output on the M6 and RV200 chips (Radeon Mobility and Radeon 7500). The patch eliminates an 8-pixel horizontal offset needed to align the overlay with the frame buffer. I added suitable code which checks for the M6 and Rv200, and also removed the part of the patch which broke video on 15 bit and pseudo color visuals. A single binary now works on all of my radeon chips (7500, M6, 8500). It needs testing on earlier chips (SDR, DDR radeons, 7000, 7200). If anyone is interested, please download the patch and apply it to current CVS before Kevin lands a giant merge from ATI. http://keithp.com/~keithp/download/radeon_video.diff Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Slow opaque window resizing
Around 17 o'clock on Jun 26, Soeren Sandmann wrote:
> The behaviour where the client stops drawing completely is not
> difficult to get with a moderately complex gtk+ 2.0 application and
> the X server running without -dumbScheduler.
Please give the enclosed patch a try -- it transfers scheduling credits
from the WM to the app on reconfigure. It works quite nicely in my tests,
making a marked improvement in mozilla resize behaviour.
-keith
Index: dispatch.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/dix/dispatch.c,v
retrieving revision 3.27
diff -u -r3.27 dispatch.c
--- dispatch.c 19 Feb 2002 11:09:21 - 3.27
+++ dispatch.c 26 Jun 2002 17:01:47 -
@@ -344,6 +344,43 @@
}
return best;
}
+
+/*
+ * When a window manager manipulates a client window,
+ * swap scheduling priority between the two so that the
+ * client runs next.
+ */
+void
+SmartScheduleYield (ClientPtr current_client, XID next_rid)
+{
+intnext_index = CLIENT_ID (next_rid);
+ClientPtr next_client;
+
+if (next_index && (next_client = clients[next_index]) &&
+ next_client != current_client)
+{
+ if (current_client->smart_priority > 0)
+ {
+ longbonus = current_client->smart_priority;
+ ErrorF ("0x%x/%d yielding to 0x%x/%d\n",
+ current_client->clientAsMask,
+ current_client->smart_priority,
+ next_client->clientAsMask,
+ next_client->smart_priority);
+ current_client->smart_priority = 0;
+ next_client->smart_priority += bonus;
+ if (next_client->smart_priority > SMART_MAX_PRIORITY)
+ next_client->smart_priority = SMART_MAX_PRIORITY;
+ }
+}
+
+}
+#define CHECK_YIELDTO(c,id) (((c)->clientAsMask != ((id) & ~RESOURCE_ID_MASK))?\
+SmartScheduleYield((c),(id)) : (void) 0)
+#endif
+
+#ifndef CHECK_YIELDTO
+#define CHECK_YIELDTO(c,id)
#endif
#define MAJOROP ((xReq *)client->requestBuffer)->reqType
@@ -686,6 +723,7 @@
if (!pWin)
return(BadWindow);
MapWindow(pWin, client);
+CHECK_YIELDTO(client,stuff->id);
/* update cache to say it is mapped */
return(client->noClientException);
}
@@ -759,6 +797,7 @@
return BadLength;
result = ConfigureWindow(pWin, (Mask)stuff->mask, (XID *) &stuff[1],
client);
+CHECK_YIELDTO(client,stuff->window);
if (client->noClientException != Success)
return(client->noClientException);
else
Re: [Xpert]Slow opaque window resizing
Around 12 o'clock on Jun 25, Owen Taylor wrote: > I talked about with this Keith at some point and he thought it > should be easy to fix, but I don't remember the details. > > Like many scheduling problems, it is, fundementally an architectural > problem. Ideally, the window manager should wait for the client before > processing the next step in the resize; but it's really hard to do > this with the Window manager / client separation in X. Hmm. It may be as simple as having the X server transfer scheduling credits from the WM to an application when the WM reconfigures an application window. Now the WM will be put to sleep and the app will run. That should be easy enough to test too. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: 10-bits per colour
Around 18 o'clock on Jun 20, "Dean S. Messing" wrote: > As for "no LCD screen can output this level of colour", this is also > not correct, though you won't be able to buy such a Flat Panel at > Best Buy or Circuit City (yet). > > http://www.presentationmaster.com/2002/04_apr/news/cw_sharp_lcdmill.htm Hmm. Looks I need to do more research in color space conversion and monitor calibration -- one must always direct ones research towards the area with the nicest toys... Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xscope version
Around 1 o'clock on Jun 19, Paul Anderson wrote: > The changes involved adding an mini-infrastructure to decode extension > requests, replies, errors, and events, so that extensions can be added > easily and in a modular fashion. At the time, this did what I wanted with > the least impact to the original source code. I'm sure others who have > added extension tracing have made similar changes. I suspect most of us added extension support in a rather ad-hoc manner. It would be nice to have a better architecture in place. > If there's interest, I can work to get this contributed under > the proper license. That would be nice, but it does depend to some degree on how hard you think that will be. It is getting easier to open-source code from HP these days though. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Xscope for XFree86
I have good news today. Matthias Clasen found the original xscope author, James L. Peterson. I exchanged a few email messages and he sent me a version of xscope with the MIT license. I've made his version available at http://keithp.com/~keithp/download/xscope.tar.gz I have an older version that I added support for a variety of extensions available in my CVS repository, which can be located through http://keithp.com. That version has the wrong licenses in each of the files from James. I'd like to get xscope into the XFree86 distribution, but we need to collect all of the various versions that are out there and merge them together. Please let the list know if you've got other xscope fixes available or have an interest in helping merge these things together. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Appearance in X...
Around 17 o'clock on Jun 7, Rolland Dudemaine wrote: > If so, wouldn't it be a good idea to make the default fonts true type ? > Then, the fonts would look good by default. And "basic" people would not > complain about this ugly font problem anymore... Good TrueType fonts are not freely redistributable; we simply don't have any good fonts to give you, as much as we'd like to. Building a beautiful font is a lot of work, and we're lucky to have several of those donated by Adobe, Bigelow & Holmes, Bitstream, and IBM. Display these fonts on a 1200dpi printer and they look great. Display them on a 100dpi monitor, and they don't look so great. The problem is in the translation to the low resolution on the screen. Apple designed the TrueType font format to include a sophisticated "hinting" system -- essentially a programming language for adjusting the shape of the glyphs in low resolution environments to improve the legibility of the glyphs. The fonts that we ship today don't take advantage of this hinting mechanism and instead rely upon the automatic hinter provided within FreeType. Oddly, the carefully hand-generated hints provided in the best TrueType fonts generally produce better looking results than the font-independent automatic hinter provided by FreeType. There are other issues in the US surrounding Apple patents on this particular TrueType technology; many distributions of FreeType 2 disable the interpreter for fear of these patents, so in that environment, the the highest quality TrueType fonts with extensively tuned hints will look no better than the essentially unhinted fonts included in XFree86 today. There are hints in Type1 fonts, but they aren't quite so instructive, they're more like guidelines to be interpreted by a knowledgable expert. The Adobe Type1 rasterizer generates pretty good looking results even from these vague hints, the FreeType Type1 rasterizer doesn't do so well. Even still, TrueType hints appear clearer on the screen (to my eye) than Type1 fonts rasterized by the Adobe Type1 font engine. One easy thing to do in this situation is to disable hinting fonts that don't have good hints -- the results on the screen are often an improvement in apperance, even while they are significantly less sharp as most of the glyph edges aren't located at pixel boundaries. Xft2 allows you to do this in the font configuration file, simply add false to your ~/.fonts.conf file (or /etc/fonts/fonts.conf for a system-wide effect). But, the best results (for me) are gained by downloading the freely available (as in beer) web fonts from MS and rebuilding your freetype library to enable the bytecode interpreter. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Render support in Xclock by default?
I've hacked Render support into Xclock and checked that code into CVS (use 'xclock -render'); the question this evening is whether that should be the default when the Render extension is supported. Unless people have strong objections, I'll go ahead and commit a change to CVS that uses Render when available and otherwise leaves the current behaviour unchanged. Polite comments on the fine choice of default colors in Render mode would also be appreciated; I realize my limitations in the area of aesthetics. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]TinyX Server
Around 16 o'clock on Jun 7, "Q-ha Park" wrote: > i know... i had the same trouble building TinyX from xfree86 4.2.0.. after > many tries, i just gave up. so i'm still using Xfdev built from 4.1.0 source > tree... The kdrive sources don't build any servers by default, you have to ask for each one now. Try adding: #define XfbdevServerYES #define XvesaServer YES to your host.def file. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Stipple Pattern Question.
Around 11 o'clock on Jun 4, Pat Suwalski wrote:
> I've been trying for the last few days to find the spot where the X
> stipple pattern is defined.
in programs/Xserver/dix/window.c, around 120 you'll find:
static unsigned char _back_lsb[4] = {0x88, 0x22, 0x44, 0x11};
static unsigned char _back_msb[4] = {0x11, 0x44, 0x22, 0x88};
Set these to zero and you'll have a black root window by default. You'll
also get black when you do 'xsetroot -default' with this change.
Keith PackardXFree86 Core TeamHP Cambridge Research Lab
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]modelines for hdtv?
Around 8 o'clock on Jun 3, Dr Andrew C Aitchison wrote: > That might be nice, but Xlib.h has DisplayWidth() and DisplayWidthMM(), > (ditto for height) and these can be set in the config file or probed via > DDC. From these you can get the pixel pitches and aspect ratio (although > this does assume similar screens for Xinerama). I can see that a completely > free ratio makes snapping difficult, but it would be nice to have the > choice of saying let the server calculate the pixel aspect ratio. Xft is about to start ignoring the screen size entirely; the values present there are generally not what people really want (ref: last year's discussion with some torvalds goon on this topic). And, most people generally want the system to assume the pixels are square; it makes things "look better" when they have symmetrical pixels, rather than symmetrical size. It takes a rather significantly non-square pixel size ratio to make this relevant. > Can you have a "probe the pixel aspect ratio value from server > information" option ? I'll consider how this might look in the config file. I might make it look for an X resource; that could be trivially set at login time by the user. > Sorry, are you saying that that an aspect ratio of 1.2 is rounded to 1.0, > or that it is partially pixel aligned ie snaps on a 5:4 ? > IIRC TVs use a pixel aspect of 1.2, so it isn't an idle speculation, > I take it that with this change square characters remain square. The outlines are scaled separately in X and Y dimensions, then if hinting is enabled, the coordinates are shifted around to fit them to the pixel grid as appropriate. The result is that equal distances in the outline will remain approximately equal in the result, except that some distances will be adjusted to improve the appearance of the glyphs. Square characters will remain approximately square. Snapping the aspect ratio to whole integers would have been pretty boring :-) Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: KDrive doesn't like my mouse
Around 9 o'clock on Jun 3, Juliusz Chroboczek wrote: > So it looks like the Synaptics touchpad reacts to the Intellimouse > initialisation sequence by switching to some weird protocol. Do you > have any suggestions for fixing that, other than disabling > Intellimouse support? One suggestion would be to try to id the Synaptics before sending the sampling rate commands -- those are required to get the IMPS/2 mouse to id itself as an IM instead of a regular PS/2. You might also poke about on the net; there are hacks for the synaptics touchpad which people have posted which adjust all kinds of cool parameters, the synaptics touchpad is used in lots of laptops; perhaps those hacks have some helpful information. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]modelines for hdtv?
Around 13 o'clock on Jun 2, Keith Packard wrote: > I think I'll add an aspect ratio field to allow the right thing to > happen. Yes, that looks much better now -- aspect ratios of 1.2 still snap glyphs to the pixel grid to make them appear sharper when hinting is enabled. With current CVS, you can edit .fonts.conf to include: 0 1 aspect 2 And, you can specify the aspect ratio in a font name: $ xclock -digital -render -fa 'times:aspect=4' These effects are cumulative; with both in place, the font will be displayed 8 times as wide as normal. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]modelines for hdtv?
Around 17 o'clock on Jun 2, Dr Andrew C Aitchison wrote: > You can use the DisplaySize option to tell the X server what size the > screen is. It will then tell any app that asks the horizontal and > vertical pixel pitches (dpi), but this confuses sufficiently many apps > that by default we don't set this from the DDC info. > The RENDER font system could probably cope, but most apps don't get > anything sensible out of the old font renderer. Xft assumes that pixels are square; users and applications generally expect the dpi to be equal along each axis, so Xft plays along. Fixing that would be pretty easy; I could add an 'aspect ratio' field to Xft that could be configured per display. Certainly the underlying rasterizers are more than willing to draw with non-square pixels. You can actually do something similar, but not quite the same by setting a matrix when rendering text. The problem with using a matrix is that the matrix is applied after the hints; that makes the characters always appear the same, independent of the matrix, but makes the transformed characters no longer aligned to pixel boundaries. Disabling hinting would at least make them appear no worse under transformation. I've tried this with Xft2 and (after fixing several bugs), it works just fine. I think I'll add an aspect ratio field to allow the right thing to happen. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: use of pseudoColor in v4.2.0
Around 11 o'clock on May 28, Dr Andrew C Aitchison wrote: > We should probably address this deficiency for the next release :-) I've already fixed Render so that it doesn't consume the entire colormap; the appropriate fix is to make that number configurable. Render is useful even on pseudo-color screens as it permits applications to efficiently draw text using client-side fonts. I stronglye believe that Render is a necessary part of a modern X server; those without it should be considered "broken". Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]To xfs, or not to xfs? Is the question...(Was: Bug#147898: xserver-xfree86: freeze when using TrueType with Xinerama)
Around 9 o'clock on May 26, =?iso-8859-1?Q?Jos=E9?= Fonseca wrote: > Ok. But, when not using RENDER, in the presence of xfs who does the actual > rendering: the X server or xfs? In other words, does the xfs handle > glyphs, or just the whole font files themselves to the X server? xfs uses the X Font Services Protocol which is documented in the XFree86 xc/doc directory. It sends glyphs as bitmaps. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]all color cells preallocated in pseudoColor mode in 4.2.0
Around 12 o'clock on May 24, Mark Vojkovich wrote: >People have already given you the answer, but you have disregarded it. > It is the RENDER extension that is eating up your colormap. Current XFree86 CVS reduces the RENDER extension's colormap appetite to a much more modest portion. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]monitor redetection
Around 20 o'clock on May 22, Dr Andrew C Aitchison wrote: > Monitor redetection isn't implemented at the moment. The RandR implementation in the kdrive vesa server can requery the BIOS for modes; laptop BIOSes generally reflect the changes visible when the select output is switched. I use this to switch sizes when plugging into an external projector. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Allocated colormaps and 4.2.0
Around 11 o'clock on May 22, [EMAIL PROTECTED] wrote: > now I am finding that regardless of the window manager I use, most colours > have already been allocated. Fixed in current CVS. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]cvs X: build error in lib/Xft1/xftdir.c
Around 3 o'clock on May 22, "Axel H. Siebenwirth" wrote: > I have encountered an error during make install of freshly build x from > cvs.. Sorry 'bout that -- I didn't get the changes into Xft1 that are needed to deal with changes in fontconfig. All fixed now. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
