Re: Multihead ISA
Lee Olsen writes: Hello Egbert; Egbert Eich wrote: Hello Lee, thank you for the patches! Lee Olsen writes: I have completed my tests with my supply of trailing edge hardware, and my hercules driver plays well with X440. There are two attachments, one is a tar file of the hercules driver source and the other is unified diffs in the forward direction of changes that let X440 do multihead ISA. I'd expect that there are very few people who can still test the hercules driver, but if you are willing to do the support this should not be a problem. The diffs do three things: separate color and mono resources, disable vga routing for busses that don't have routing functions, and let the configure process collect ISA resource usage like it does for PCI. I don't understand this. The configure process is not there to collect resources. This is done during xf86ConfigIsaEntity(). This function should not return an allocated ScreenInfo structure if it finds conflicts. Unresolvable ISA resources should really disable both confliciting resources. The problem is resource conflicts are fatal. If a vendor specific Probe() succeeds, then the vesa and vga probes must fail. It might be different if resource conflicts propogated That's what you want. You probe as long as you found a driver. The vesa and vga probes are at the end as they are considered fallbacks only. If you want the vesa driver even if a chipset driver exists you need to use a config tool. Also the autoconfiguration will always try to get you the chipset specific driver. back up and became PreInit() failures, but that's not the case. The question is how do you know if the current Probe() should fail? The Probe() function should fail if the driver isn't able to identify a chipset as his. It also fails if another driver has allocated the (fixed) resources the driver wants. This should happen on the second pass thru configure. The existing code checks to see if any non-PCI devices have been configured and if so, forces subsequent non-PCI Probe()s to fail. What I'd like to do is use the Yes. for (i = 0; i nDevToConfig; i++) if (!DevToConfig[i].pVideo) return NULL; Does that. resource list to tell me if the device being Probe()d has been successfully Probe()d by a different driver. If so, the current Probe() should fail. Since the resources are exclusive, any overlap means two drivers want the same device. MatchIsaInstances already had the resource data, it just needed to use AddBusDeviceToConfigure() to make it available to DoConfigure(). Ah, I see. OK, I understand that. For PCI we do: for (i = 0; i nDevToConfig; i++) if (DevToConfig[i].pVideo (DevToConfig[i].pVideo-bus == pVideo-bus) (DevToConfig[i].pVideo-device == pVideo-device) (DevToConfig[i].pVideo-func == pVideo-func)) return NULL; For ISA we obviously have no ID to identify the device :-/ so you are using the resources as an identifier. Well, I guess one can do that. On the other hand DoConfigure does a second pass thru Probe() - this time it doesn't set PROBE_DETECT, therefore xf86ConfigIsaEntity() is called and should do the same thing, namely to check for conflicts with a previously detected device. I must admit I forgot the details, maybe there is some other reason why it doesn't work this way. Have you checked? 1. The minor issue: You are deleting xf86AddDeviceToConfigure() It looks like that this function is not needed any more. However it may have to be kept for backward compatibility as it is exposed to drivers. We have no information if older binary only drivers use it (although I don't think so). I had not considered third party drivers. It does not need to go away, nor it's reference in loader/xf86sym.c. Right. I cannot say for sure anyway, it may well be that we are carrying dead code around for nothing. But that's the problem with a public API: you have to support old versions of it until you say, here we need to make a backward incompatible change. Then you can drop all this, too. 2. You are splitting the mono and color resources. This is good, however it may cause problems: VGA devices may be configured to use the monochrome resources. I've seen BIOSes doing that when they find another card with color resources. Therefore we are allocating both sets of resources. We need to think how deal with that. I'd suggest to continue to allocate both mono and color resources for PCI devices as those resources are shared anyway. For ISA devices it is a little bit more difficult. Since we don't know if the device we are probing is the one we are interested in or another one. There are three sets
Re: Vesa Driver Probe
David Dawes writes: My point is that this is just one example of a class of problem that is not unique to the vesa driver. Therefore solving it within the vesa driver, while useful, does not solve the underlying problem. Also, this class of problem is not limited to vintage hardware. With the configuration work I'm doing, I'm interested in dealing with the underlying problems. Right this class of problems includes all cases where drivers may support a certain chipset but not the specific combination of hardware found on a card - like DACs. In this case an automatic configuration mechanism needs to make decisions about a possible fallback path and this can only be done after PreInit() returns - like many other cases where a specific mode may not be supported and the configuration mechanism has to decide about possible tradeoffs and fallsbacks. Lee was calling for a change in paradigms in '-configure' to overcome its weaknesses. It attempts to detect any hardware it can find provided it is either generically detectable or there is a device specific probe for it. It doesn't guarantee that all hardware it detects will run. It will also fail if a certain HW cannot be probed generically or has a specific probe function. The future may however be an automatic configuration process that dynamically attempts to find the optimally possible settings. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multihead ISA
Hello Lee, thank you for the patches! Lee Olsen writes: I have completed my tests with my supply of trailing edge hardware, and my hercules driver plays well with X440. There are two attachments, one is a tar file of the hercules driver source and the other is unified diffs in the forward direction of changes that let X440 do multihead ISA. I'd expect that there are very few people who can still test the hercules driver, but if you are willing to do the support this should not be a problem. The diffs do three things: separate color and mono resources, disable vga routing for busses that don't have routing functions, and let the configure process collect ISA resource usage like it does for PCI. I don't understand this. The configure process is not there to collect resources. This is done during xf86ConfigIsaEntity(). This function should not return an allocated ScreenInfo structure if it finds conflicts. Unresolvable ISA resources should really disable both confliciting resources. Appearantly you are trying to make the result of configure more reliable. Currently configure only takes the results of Probe() into account and doesn't care about resource management. Configure will only try to detect the devices, it doesn't guarantee that the devices it has found will really work. This will decided when the server is really started. It will pick those devices from the config file and enable them that are capable to run. If no device is the server is going to fail. The automatic configuration mechansim David has designed instead uses the results of PreInit() to make decisions and look for possible fallbacks. Without hardware to test it, you may not want to add the driver to the source tree, but it would be nice if the diffs or their functional equivalents did make it. If you'd rather this went through bugzilla, I can do that. I didn't see how to upload files on the Create bug page, but that could be bad eyesight on my part. That's fine. If you want to go thru the bugzilla you can create an attachment to an already created entry to include your diff. Ideally you would not attach them compressed, this makes it easier to review them on line. However this matter is educational so lets discuss it here. I have two issues: 1. The minor issue: You are deleting xf86AddDeviceToConfigure() It looks like that this function is not needed any more. However it may have to be kept for backward compatibility as it is exposed to drivers. We have no information if older binary only drivers use it (although I don't think so). 2. You are splitting the mono and color resources. This is good, however it may cause problems: VGA devices may be configured to use the monochrome resources. I've seen BIOSes doing that when they find another card with color resources. Therefore we are allocating both sets of resources. We need to think how deal with that. I'd suggest to continue to allocate both mono and color resources for PCI devices as those resources are shared anyway. For ISA devices it is a little bit more difficult. Since we don't know if the device we are probing is the one we are interested in or another one. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Vesa Driver Probe
Lee Olsen writes: David Dawes wrote: The Probe() function should not change the hardware state and should be as non-intrusive as possible. When Probe() reports success, it does not mean that the driver's PreInit() will succeed. The vesa driver is not especially unusual in this respect. Why do you need to change this? That is exactly the misunderstanding I suffer from. If X -configure creates a config file, I expect it to work with the hardware just configured. If Probe succeeds and PreInit fails, then the configuration isn't valid. When That's correct to some extend. However you will never find a system that will be capable to reliably configure every environment in the world. The ISA probing of 3.x - which was really a work of art - has been abandoned in favor of better modularity and PCI support. The probe function works well with PCI cards and it can be made to work with ISA cards (some drivers have ISA probing functions). However even if all drivers that still support ISA cards provide a probe it is not guaranteed that this will work with -configure. The trick of 3.x (and SuperProbe) was to probe the hardware in just the right order that avoided detection of a chip by the wrong driver. it's something like the ati driver configuring a screen for a VGA-less 8514 and failing in PreInit, that's not a big deal because it's very likely there's a VGA head supported by another driver. I figured a single-headed configuration shouldn't do this. With the trailing-edge cards I'm testing for vga/mono conflicts generally using the vesa driver, I wanted to eliminate the No screens found distraction. Fortunately it's a want rather than a need, and based on Egbert's comments, a bigger can of worms than I want to deal with right now. That's very unfortunate. The VESA driver could use some more work. It is quite useful but there are a lot of things that could be improved given that we have a much better environment for vbe. Since X -configure won't generate a vga device entry, Egbert's ideas about doing vga stuff in the vesa driver might be the right long term solution. At least it brings Probe and PreInit back in sync. Yes, and it shouldn't be hard to implement. Just that most of us have more urgent things on their agenda. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Vesa Driver Probe
David Dawes writes: Could it be done by simply looking for a string in the BIOS image? Probably. In general, relying on the result of Probe() to select the correct driver is flawed though. There are many cases where Probe() can succeed but PreInit() will fail. The latest automatic configuration code I have handles this and should fall back to the vga driver for a non-VESA vga card. We are going to want to rework some of these things to better handle automatic and dynamic (re)configuration. Right. However vga doesn't seem to be the most generic fallback solution. Whatever the vga driver can do could be done using the ancient de facto standardized vga BIOS modes - those modes that existed before every vendor started to do his own thing (called SVGA) and long before VESA appeared on the scene to try to sort out the mess. This could be handled within the vesa driver itself. This however addresses a marginal market today as not too much of this vintage HW seems to be around any more. Also I'd expect that one who does attempt to use a recent version of X (and probably also a recent version of the other components) will run into other obstacles. In this respect the sligtly more complicated configuration may be a lesser problem there. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Vesa Driver Probe
David Dawes writes: On Sun, Mar 28, 2004 at 05:14:39PM -0800, Lee Olsen wrote: Hello all; The vesa driver probe/FindIsaDevice is doing a vga probe, not a vesa one. It should be calling a vbe routine to check for a vesa signature. The Probe() function should not change the hardware state and should be as non-intrusive as possible. When Probe() reports success, it does not mean that the driver's PreInit() will succeed. The vesa driver is not especially unusual in this respect. Why do you need to change this? What Lee is trying to do is to call the BIOS to detect if the VESA ID can be found. This should not change the HW state (if we *assume* BIOS is sufficiently sane). It should not be more intrusive than what drivers with ISA probing already do - including the vesa driver. The advantage of such a probing in Probe() would be that the -configure option works. On the other hand of course it would require changes to the int10 system to be able to work without a valid entity. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: vesa probe is inadequate
Hi Lee,
Unfortunately your patch is backwards.
Furthermore I'd personally prefer unified over context diffs.
Lee Olsen writes:
Hello all;
The vesa driver's probe only looks for a vga. If you have a real stone
age original vga, you get
No screens found. The vesa probe needs to look for the vesa signature
in the bios, and that
means libint10.a and libvbe.a must be able to run without referencing
screens or entities, which
they both do.
You mean you want to map the BIOS memory and search it for the signature.
The diffs that follow avoid entity and screen references for indexes
less than zero and behave
as before for positive values.My copy of the vesa driver has some
multihead isa stuff in it, so
I have sepent some time thinking about multihead ISA.
The only chance for it to work appeared to be if ISA cards
are capable of remapping their registers. This is scary as
there is no range they can do this savely (except for the
8514 regsters). However I never had any cards with docs that
I was able to try it so I gave up on it.
Furthermore I would have expected that at boot time both
cards would have their default registers VGA enabled
which will definitely produce problems during POSTing.
Not to speak of the problem that arise if both cards map
their ROM into the same range.
Therefore I'd expect that this has only a chance to work
if you are able to disable the standard VGA registers and
BIOS on one card entirely (using jumpers) in which case I
don't understand how the VESA driver would be of any help
for such a card.
I'll save that for later. Since these are independent, I'm presenting
them without the multihead
clutter. I'm not sure I got everything, but it tests correctly for pure
isa vga, pure isa vesa, and
pci/agp/no isa. I don't think my bios will let me put an isa video card
in the pci/agp box.
The two line vbeModes.c change fixes VBEFindSupportedDepths reporting
zero for depths
les than 15. The symptom I saw is a 512k card requesting a depth of 16,
resulting in No usable
modes.
Enjoy
Lee
diff -c helper_exec.c*
*** helper_exec.cMon Mar 29 11:35:02 2004
--- helper_exec.c.origTue Dec 23 14:32:38 2003
***
*** 581,587
unsigned char* base;
int i;
! if (!save !pInt-BIOSScratch)
return;
base = xf86MapVidMem(pInt-scrnIndex, VIDMEM_MMIO, 0, pagesize);
--- 581,588
unsigned char* base;
int i;
! if (!xf86IsEntityPrimary(pInt-entityIndex)
! || (!save !pInt-BIOSScratch))
return;
I'd say this is not valid. xf86Int10SaveRestoreBIOSVars()
copies the physical BIOS variable area to and from the scratch
area. This physical area exists only once and belongs to the
primary card.
The physical BIOS area is set up during posting. Therefore
the values are only meaningful for the card that got posted,
not any other card.
base = xf86MapVidMem(pInt-scrnIndex, VIDMEM_MMIO, 0, pagesize);
End of helper_exec.c changes
For the rest of the diffs:
I guess what you are trying to do is to get the BIOS mapped
although you don't have an entity index (yet).
That's easy for primary cards. For non-primary cards it is
only possible for PCI cards. It looks like you only need
the BIOS, you don't need any int10 functions.
We therefore should check if we can separate out the mapping
part and make it available as a separate function.
diff -bc vbeModes.c*
*** vbeModes.cMon Mar 29 15:24:45 2004
--- vbeModes.c.origThu Nov 6 10:38:14 2003
***
*** 54,61
depth = 1;
}
bpp = mode-BitsPerPixel;
- if (!depth)
- depth = bpp;
VBEFreeModeInfo(mode);
mode = NULL;
switch (depth) {
Hm, that one seems to work around a bug in the BIOS I
assume.
Egbert.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: vesa probe is inadequate
Lee Olsen writes: Egbert Eich wrote: You mean you want to map the BIOS memory and search it for the signature. I believe I want to use int10, function 0x4f, subfunction 0, as is done in VBEExtendedInit. There may be other, less intrusive ways. OK. In this case we should *assume* that the card is VESA and fail later if this fails - or better yet add a fallback to the lame pre-VESA BIOS video modes that were standardized and only fail if those don't work either. Now that I rechecked my vesa driver diffs, you're right. I'm chasing a zoom problem and not doing any multihead stuff there. OK. I don't expect to run multiple isa VGA cards in the same box. I don't see how to remap VGA resources either. I do expect 8514, VGA, and mono to coexist. If there are other Yes, I actually think so too. However I'm not so sure about VGA and mono as they do seem to share some registers. I'd assume that a genuine hercules mono and ISA cards would work together. However I think we dripped the herc driver a long time ago since noone had a card to test this with anymore. All this would be more or less academic anyway - a good practice to get the fingers wet, however one should not expect that it will have real relevance. isa cards that can disable VGA features like the Graphics Ultra Pro, they can be added to the list. Right. I'll save that for later. Since these are independent, I'm presenting them without the multihead clutter. I'm not sure I got everything, but it tests correctly for pure isa vga, pure isa vesa, and pci/agp/no isa. I don't think my bios will let me put an isa video card in the pci/agp box. The two line vbeModes.c change fixes VBEFindSupportedDepths reporting zero for depths les than 15. The symptom I saw is a 512k card requesting a depth of 16, resulting in No usable modes. Enjoy Lee diff -c helper_exec.c* *** helper_exec.cMon Mar 29 11:35:02 2004 --- helper_exec.c.origTue Dec 23 14:32:38 2003 *** *** 581,587 unsigned char* base; int i; ! if (!save !pInt-BIOSScratch) return; base = xf86MapVidMem(pInt-scrnIndex, VIDMEM_MMIO, 0, pagesize); --- 581,588 unsigned char* base; int i; ! if (!xf86IsEntityPrimary(pInt-entityIndex) ! || (!save !pInt-BIOSScratch)) return; I'd say this is not valid. xf86Int10SaveRestoreBIOSVars() copies the physical BIOS variable area to and from the scratch area. This physical area exists only once and belongs to the primary card. The physical BIOS area is set up during posting. Therefore the values are only meaningful for the card that got posted, not any other card. The diffs I provided are a minimal set that allowed the probe to run. This is the kind of feedback I was hoping for. What is the right way to do this? As I mentioned above you may just assume that the card is VESA capable. The ISA card VGA detection was added to see if there is an ISA card at all. One can change the probe function to believe the user if he has added such a card to the config file or better extend the probe function to check for the presence of some other (standard) register sets (8514). As a last resort we could add something like you propose if the driver explicitely asks for it. I do see a valid point that someone may want to probe the primary card prior to assigning any entity to it. It must be clear however that anything that is allocated for this probing is cleaned up before Probe() exists as the driver must not assume that the probed chips are really used. Cheers, Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: __AMD64__ or __amd64__ ?
Matthieu Herrb writes: Hi, While working on OpenBSD/amd64 support for XFree86, I found out that the C preprocessor symbol for AMD64 machines was changed from __x86_64__ to __AMD64__. But looking at what gcc defines on different AMD63 systems (*BSD, Linux), it looks __AMD64__ is never used. Generally __amd64__ is defined. linux.cf add -D__AMD64__ to StandardCppDefines, so the code actually works there. Also, in many places where checks are done for 64 bits arches, the test is in the form #if defined(_LP64) || defined(__alpha__) || defined(__AMD64__). Since on the BSDs gcc defines _LP64, these conditions will be true. But there are a few cases where the _LP64 test is missing. LP64 should be set correctly by more recent versions of gcc and should be used instead of the architectural defines for identifying wether long is 32 or 64 bit. I would think that any versions of gcc for AMD64 which were ever released to the wild seem to set this correctly. Any clues on how to fix that correctly (after 4.4) ? Instead of enumerating all the LP64 arches in several different places, it would be better imho to make sure _LP64 is defined and only testing on this. For other cases (where the dependance is not a general LP64 problem, but AMD64 specific, it would be more logic imho to use __amd64__. Right. It should be straight forward to change this. I used a script to change it fron __x86_64__ to __AMD64__ when AMD announced this name. (That was what I was told to use if I remember correctly). However everything should work as long as the define __x86_64__ is still supported by gcc. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver
Craig Ringer writes: On Tue, 2004-02-24 at 22:55, Alan Hourihane wrote: We could leave the option in, but enable it by default, so that this information is displayed, and allow people to turn it off if it hangs. Additionally, why not print a log line like Some versions of this video BIOS have a bug that will cause XFree86 to hang. If you encounter this, try setting the BLAH option in your config file. It should save a bunch of questions on [EMAIL PROTECTED] Yes, this sounds like a good idea. It should be printed right before the offending call so people will see it. The system does not hang hard therefore people should be able to retreive their log. On the other hand they may not know how to do it in this case. Sill, such a message may be worthwhile. I will add it together with the changes Alan suggested. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver
Christian Zietz writes: Hi, as I already pointed out some of the users affected by the problem don't want to or aren't able to build XFree86 out of the CVS sources. So I wrote a small hack which wraps around int 0x10 and prevents the function in question (ax=0x5f64, bx=0x0300) from being called. I'm aware that that's a much dirtier solution to the problem than the patched driver but nonetheless I think it might be useful for people who want to use the precompiled XFree86 that came with their distribution. Download URL for 855wrap: http://www.chzsoft.com.ar/855wrap.tar.gz I think it would be worthwhile to investigate the origin or the problem and report it to Intel to fix it in the BIOS - in case they have broken something. It looks like an endless loop to me. Since the problem appears both to happen inside the emulator and vm86 mode it points to the BIOS however we cannot say for sure. One may want to try to set up registers and execute this command from 'debug' inside DOS to see if this ends up in an endless loop also. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver
Christian Zietz writes: Hi, as developer of 855patch I get a lot of feedback from people using XFree86 on computers with i855GM graphics. It seems like new notebooks by Dell feature a new video BIOS from Intel (iirc Build 3066) which finally implements the int 0x10 0x5f11 function to set the amount of video RAM and thus making 855patch obsolete. But the i810-driver refuses to work on systems with that BIOS version. I had several independent reports of users who just get a completely green screen when starting XFree86. I had a look on a log file and found nothing unusual. The XFree86 VESA driver however works but just in low resolutions/color depths as there is no way to allocate more video RAM there. As I've been absent of this list: Is this already a known issue? I haven't heared anyting about this issue yet. The first question that comes to my mind is: What happens if a low resolution mode that works with VESA is set on the i8xx driver? Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.
Benjamin Herrenschmidt writes: Losing the ability of porting code straight from these to the fbdev drivers will basically kill all my efforts to turn the kernel radeonfb into a decent driver as I need to be able to re-use the code ATI puts in the XFree version. I suppose the same will happen to linux rivafb. Relating to that: exchanging code between XFree86 and kernel has been a one-way road so far. The GPL the kernel is under doesn't allow us to port back improvements that have been made to the kernel to our drivers Even though this isn't covered by the GPL the author of the driver or the changes could still give the permission to do so. I whish there was a better exchange between kernel fbdev developers and driver developers here. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.
Sven Luther writes: Maybe a decision on both parts on this would be ok ? XFree86 could make sure the licence of the driver code would not conflict with the GPL, keeping the old one for example, and the fbdev driver authors would dual-licence the code, both GPL and the old xfree86 licence would do just fine. Benjamin, what do you think about this ? BTW, CCing this to the linux-fbdev mailing list. Yes, a personal agreement between driver developers would also work. However they tend to change and other people will make contributions who all would have to agree also. I don't know if a general dual license agreement in the kernel file header would be possible. Also it could get removed once the author changes. Just like the license in the XFree86 driver could be amended. Doing this now for existing fbdev driver would involve to ask anyone who has contributed little more than a typo fix. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: building X11 in separate pieces
Mario Klebsch writes: Hi! Am Samstag, 10.01.04 um 13:40 Uhr schrieb Warren Turkal: Mario Klebsch wrote: But without digging to deep into that question, does freedesktop only provide an alternative xlib or do they offer an alternative to XFree (providing a complete set of libraries (xlib, Xt, Xaw, ...) and the imake based build system? Freedesktop is intending to produce a full set of xlibs. All of the libs we have packaged are built with autotools. We have also broken many of the libs into their own packages so that pieces can be upgraded independently. We have added pkgconfig support to all libs so that autoconf can more easily detect libs and compile flags and link flags needed. I never understood why so many people consider these autotools easier to use than the imake system. Imake (or to be precise, the config files It is not. The reason why people advocate the change simply is that autotools are more widely used and therefore more people are aquainted with them. The vast majority of people know only either one or the other and therefore are not able to judge if such a step would be feasable and what consequences this may have. Unfortunately noone who has knowledge of both systems and advocates the change has ever provided a ... This however is needed to start a fruitful discussion on the issue. - Imake's strong area is the generation of Makefiles: Many Makefiles in X are boilerplate. For those Imake uses macro templates in its config file. The Imakefiles using these macros are very short, the programmer doesn't have to worry about the details of the build this is done once only: when the build macro was created. Adding new macros is simple. In most cases the build macros will already pick the right set of command line parameter definitions so the Imakefile writer doesn't have to worry about these. - autoconf's goal is to query all system/platform dependent parameters dynamically at build time. This makes porting to new platform quite easy: in most cases nothing needs to be changes because all necessary probes are already performed. Imake requires a static configuration for each architecture/ platform/version. It only probes a few system dependent parameters to be able to pick the correct configuration. Porting to a new version/ architecture/platform involves adding a new or extending an existing configuration. - autoconf does not simplify Makefile writing: The required Makefile.in has the same content as the resulting Makefile with system dependent parameters replaced by tags which will be substituted by configure. This is where automake steps in: automake knows how to make build rules for the build targets described in the Makefile.am. It knows about a large number of standard build targets, the generated rule can be controlled by additional arguments as for example extra command line options. These options need to be specified in every Makefile.ac that requires them. Extending automake with new build targets/ build rules doesn't seem to be as easy as it is with Imake. - The number or supported vendors/platforms/systems/architectures have turned the Imake rules and template files in to a giant mess which only a small number of people are still able to handle. Either these files have become more complicated than required (in which case they could be simplified) or I expect that porting over this mess to autotools while keeping intakt every specialty required will be close to impossible. I'd therefore expect that using autotools will always mean a tradeoff when dealing with very special build targets. Recently the suggestion has been made to replace the static configuration files with a dynamic configuration created by autoconf/configure. In fact this idea is not new: I rememer RMS proposing this idea four years ago already. This in fact may perserve the benefits of Imake while it would reduce the system dependent configuration mess and make porting easier. It may also be possible to integrage libtool which would then allow to do away with the system dependent rules and template files for shared libraries building. In principle Imake should also support buidling of individual parts of the X sourcetree provided the config template and rules files as well as the header files are installed somewhere on the system. Unfortunately this did not always work when I checked last. included with X11) knows everything about the local X11 installation, where configure has to guess and far too often guesses wrong. I really do see no benefit in not using the imake system and I must admit that I do not understand why configure does not use an Imakefile to find out all the details needed to compile X11 programs on a given platform. When I did not know the details of how the automatically generated configures work, I often spend hours on getting this
Re: SPLIT_WC_REGIONS - anyone out there?
Alexander Stohr writes: Hello, i stumbled across the above mentioned define and related code in the XFree86 sources (lnx_video.c). comparing X4.1.0 and X4.3.0 i found that the condtitnal coding of if (base % size) has vanished at some point in time and the handling is now hardcoded at this code location. The old code was broken. It created to many split areas which were unnecessary. to my best knowledge that coding is related to maybe the 3Dfx PCI memory regions layout with a single mixed framebuffer and register mapping. No, this code is entirely generic. A WC region needs to be a power of 2. If it is not the range has to be split up and subdevided. is any developer out there that is willing to describe the main points of that design in a few words. i am asking for that because i have had a case where the split code went into action despite any need and even the PCI range was a power of two. so in theory it should not happen. Can you give an example please? before popping up with any general solution i just wanted to make sure that i got the right idea of that code. to my understanding current mtrr implementations might be more flexible than it is assumed in the existing code. I thought I had the most general solution. If you show me an example where the code doesn't do the right thing I'll investiagte. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
Alan Hourihane writes: Well, if someone else has a chip, or wants to update and test other drivers (but be careful with DRI enabled drivers as it needs more work in the driver). Here's a patch to the neomagic that should work, and could be used as a template for the other drivers. That's all. Most Xv (if not all) use linear allocation already and will take advantage of it straight away without any furthur modifications. Index: neo_driver.c === RCS file: /X11R6/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/neomagic/neo_driver.c,v retrieving revision 1.71 diff -u -r1.71 neo_driver.c --- neo_driver.c 24 Sep 2003 03:16:55 - 1.71 +++ neo_driver.c 30 Oct 2003 10:05:04 - @@ -1685,11 +1685,20 @@ AvailFBArea.y1 = 0; I'm not sure if this will solve the problems we see on neomagic. I will take a look at it but I won't be able to do this in time for 4.4. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: C+T 69030 driver on powerpc
Rob Taylor writes: Has anyone sucessfully run the chips 69030 driver on powerpc based systems? I'm trying to get it running on a custon 7410 based board with two 69030's on,a nd i;'m seing soem off things: my /proc/pci gives me that: Bus 0, device 18, function 0: VGA compatible controller: PCI device 102c:0c30 (Chips and Technologies) (rev 97). IRQ 18. Non-prefetchable 32 bit memory at 0xfa00 [0xfaff]. Bus 0, device 19, function 0: VGA compatible controller: PCI device 102c:0c30 (Chips and Technologies) (rev 97). IRQ 18. Non-prefetchable 32 bit memory at 0xfb00 [0xfbff]. at the moment i'm just attempting single head setup on device 18, however i find cPtr-PciInfo-memBase[0] is 0xff00 when calulating cPtr-FbAddress (in chipsPreInitHiQV) , rather than 0xfa00! Does any know any reason why xf86GetPciInfoForEntity would return incorrect information, or have i got the wrong end of the stick? well I now know why i get 0xff00 for the set up device - its MBASE0 is 0x000 when we do xf86scanpci, and PCINONSYSTEMCLASSES(baseclass, subclass) is true hence pciCheckForBrokenBase gets called, which will set MBASE0 to 0x, and as only the top byte is writable (16Meg chunks) MBASE0 becomes 0xff00. not that this seems to help me much. i'm just more confused now!! why on earth would mbase0 be 0, if its in use and /proc says the device's memory is at 0xfa0???! really just posting this here incase anyone else ever wants to know... =) Can you add some code to xf86scanpci() to find out why it's 0? On PPC PCI config space data gets obtained thru the kernel, therefore it is even harder to understand. Also could you please run 'scanpci -v'? Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: C+T 69030 driver on powerpc
Rob Taylor writes: attached is 2 possible outputs of scanpci -v 1st is before running server 2nd is after! the server hangs waiting for a vertial retrace before reading ddc1, and needs to be SIGSEGV'd. the trace from the xserver, verbose 10 is also attached I had this happen to me too, once, however it turned out to be a HW failure. After I commented out this code I ran into other problems. You may comment out this code for testing, however one should try to understand why this code is causing problems. so I correct myself. looks like its nothing to do with the kernel framebuffer driver. it mroe to do with the state the card gets left in after being half configured *phew*!! so thats makes life a bit easier - i just need to fix the card configuration! This should not happen. It can only happen when the Xserver has the ROM BIOS mapped. Judging from your log that shouldn't happen. Can you find out where it happens? You can hardcode a test for the relevant PCI config space register and PCI tag in the appropriate PciWrite() function and call a function you can breakpoint from gdb. There are three functions for this purpose: xf86Break1/2/3(). Cheers, Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: C+T 69030 driver on powerpc
Tim Roberts writes: On Thu, 23 Oct 2003 17:16:19 +0100, Rob Taylor wrote: Has anyone sucessfully run the chips 69030 driver on powerpc based systems? I'm trying to get it running on a custon 7410 based board with two 69030's on,a nd i;'m seing soem off things: ... Also does anyone know the reason for the addition of 0x80 to the base address in the big-endian case? Many graphics chips include two separate views of the frame buffer: one that swaps bytes, one that does not. This makes it easy to handle endian mismatches. I'm guessing that's the case here. Right, that's exactly the reason for this. The BE support was tested for one of the HiQV chipsets - however I'm not sure if it was tested for the 69030. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 Bugs?
Marc Aurele La France writes: [EMAIL PROTECTED] is an ML anyone can subscribe to. I am, and, I believe, so is Egbert. No, not currently. I usually go to the web interface and look at the open bugs, process new ones that can be handled quickly, or try to assign them to an expert on the specific area. There are a lot more areas than we have experts - in these cases I try to work on the ticket myself. This, and the low quality of some of the submissions, consumes a considerable amount of time. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 Bugs?
Harold L Hunt II writes: What happens when I assign patches in the Cygwin Xserver project to [EMAIL PROTECTED]? Does an email go out to everyone with CVS commit access? Is there a single person that receives this email? Should I be assigning patches to a specific person to ensure timely commits? I realize that a feature freeze is in place now... this is a general questions for normal times so that I know how to assign my bugs to when I want them to get committed. [EMAIL PROTECTED] is a mailing list where interested persons can subscribe to. I don't know how though. It serves as a general 'sink' for everything that cannot be sent to a specific maintainer. If you have a patch that you would like to see committed you can assign it to me. I have to apologize that I was gone last week and in bed with a cold this week so there is a rather big backlog of patches that I was planning to commit but haven't. I will review uncommitted patches and commit them as soon as I feel better. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 Bugs?
Harold L Hunt II writes: So, who wants to handle a high volume of patches specific to Cygwin after the 4.4.0 branch? Any volunteers? I would appreciate someone that can commit to a 24 to 48 hour turnaround on committing submitted patches that don't touch other platforms. I usually try to do this. However I can only do so when I have high speed internet access. This isn't the case when I'm traveling or home with a cold. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SiliconMotion - unable to restore VGA screen on exit
Richard A. Hecker writes: I don't know if there is any XFree86 Developer in the LA area. In fact there may by fewer XFree86 Developer around the world than you expect. It seems to be a popular misconception that this project has hundreds of active developers. Egbert If you are talking about the City of Angels instead of Louisiana then I live in the northern end of the county. I keep myself pretty busy so a visit is unlikely. Possibly I'm dump. I however don't see how your contribution could further to a solution of the reported problem. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SiliconMotion - unable to restore VGA screen on exit
[EMAIL PROTECTED] writes: What is the status of the problem of being unable to restore the VGA screen using the SiliconMotion drivers? Bugzilla 124 702 have reported the problem. Some comments indicate there is a working patch, while some comments (and my experience) indicate that the problem still exits, even using the latest 4.3.99.x XFree86. It's not clear if anyone is actively working on the problem. I would add that in my case, using a Panasonic CF-28 ToughBook (laptop), the problem exists using Solaris 8 and 4.3.99.x XFree86, but does NOT exist using RedHat Linux with 4.2 XFree86 on the same machine. Also, as I reported in Bugzilla 702, using Solaris 8 and 4.0.2 XFree86 Porting Kit, I did not have the problem either. I would have fixed this problem long ago if I could reproduce it on Linux. I have dug out my Lynx3D evaluation board just recently to see if I can reproduce this problem however I don't see it. It is fairly hard to fix a problem that I don't see. If you could describe the problem a little closer one may get an idea: - Dose the monitor sync at all when you go back to text mode? - Is this a video mode restoration problem? (Do you get the same frequencies on the text console as you had before you started X?) - Are you using a 'real' text mode (or is this something like a framebuffer mode under Linux)? - Is it a font loading problem (under linux you can load a new font by doing setfont ... to test this)? - Is it a pallette problem (ie that you get black on black)? Under linux the VGAlib had some tools to save/restore the VGA palette. I would appreciate feedback on any planned efforts on this problem. If any XFree86 Developer in the LA area needs to look at my machine, I may be able to accommodate them to get this problem solved. I don't know if there is any XFree86 Developer in the LA area. In fact there may by fewer XFree86 Developer around the world than you expect. It seems to be a popular misconception that this project has hundreds of active developers. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Exporting sched_yield to the drivers
Jim Gettys writes: Most operating schedulers are much happier to give you the CPU again if you don't monopolize the CPU, and let the other processes get the CPU regularly. Generally, they boost the priority of processes that just use a short amount of CPU, and then give it back. This is typical interactive behavior of processes. Having the X server yield if it is busy is a good thing to do. Yes, I agree that there are situations where this is true. However there is not guaranteed latency. In some situations normal rescheduling just isn't enough. We'd need to get rescheduled on a certain event within a certain time window. As long as we don't have the infrastructure for that we need to loop. Most workstation based X servers have had a shared queue/pipe with the driver, fill up that queue, and arrange in the driver at interrupt level to set up the next set of commands or image transfers (to keep the hardware busy), and then the OS would typically schedule the X server process again (which would refill the command buffers). In many operating systems, there were ways to tell the operating system in the driver that the process should be woken up. That is with a driver component in the kernel I suppose. Having the X server busy wait in user mode for any significant time is a bad idea... That is definitely true. I agree that we should have some level of kernel support. It however needs to be implemented in a way that the driver will continue to build and work on OSes where this kernel support isn't available. This is one item I would like to experiment with on my (long) list of TODOs. Note that this equation has been changing in Linux greatly recently: until very recently Linux has had a sucky scheduler and has only recently started to use an O(1) scheduler like most BSD Unix systems have had for aeons (20 years). But also note that Linux has been working very hard the last couple years in general on removing latency. That's definitely true, but in these situations we have a harder RT requirement. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Exporting sched_yield to the drivers
Mark Vojkovich writes: Can we export to the drivers some function that yields the CPU? Currently alot of drivers burn the CPU waiting for fifos, etc... usleep(0) is not good for this because it's jiffy based and usually never returns in less than 10 msec which has the effect of making interactivity worse instead of better. I'm not sure which platforms don't export sched_yield() and which will need alternative implementations. I've experimented with sched_yield in drivers when waiting for retrace on video playback. It turned out that when the system was otherwise idle the video performance was about the same. However when another application was using its full time slice the video frame rate would drop far below the screen refresh rate. I've measured the latencies and it turned out that the time elapsed before the process would be rescheduled was considerably higher than the average time the process was hanging in the wait loop when the system was otherwise busy. Shorter (or variable) time slices may help here, but a better solution would be to use an event (ie. interrupt) driven rescheduling. This would require a small kernel support module for each driver, though. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Exporting sched_yield to the drivers
Mark Vojkovich writes: Your experience is out of date. If I've just filled a Megabyte DMA fifo and I'm waiting to cram another Megabyte into it, how quick is my FIFO busy loop then? I've had great success with sched_yield(). The DMA buffer case may be different than the video case I mentioned before. sched_yield may in fact be useful if such large buffers have to be processed. However it is not a general solution for every fifo wait. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: C version of ucs2any.pl
David Dawes writes: BTW, how are things like host vs target imake binaries handled when cross-compiling? Currently in most cases the installed versions are used. Only imake is compiled as HostProgramTarget(). I don't recall if a target version is ever built and installed. This should definitely be tested and fixed. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Wrong order of a timeouts processing in WaitForSomething.
Keith Packard writes: Around 20 o'clock on Sep 20, Ivan Pascal wrote: The solution is obvious. WaitForSomething should not run any callbacks before the Select but just check timers and if there are expired timers call select with a zero timeout. Also the code before the select checks screensaver and DPMS timeouts. One use for timeouts is to handle external network events, such as font server reconnect or XDMCP messages. In those cases, the timeout routine can modify which sockets will be needed in the select mask, hence the desire for the timeout routine to execute before the select (and various BlockHandler) routines are invoked. When the timeout routine fires only after select returns, the server will go through a complete scheduling interval before the BlockHandler is invoked. So what would be the way out? I suppose one could use a wakeup handler instead. This however would only work if the wakeup handler for keyboard input was called before the xkb timer handler. The latencies of other handlers that are called before the xkb handler could also cause the timer to expire with the key release unnoticed. The only way to ensure that a possible release event is detected is to read the keyboard in the xkb callback handler to check for pending release events. However I'm afraid xkb simply doesn't work that way. Another solution may be a a SIGIO driven keyboard input. Also the code before the select checks screensaver and DPMS timeouts. I don't see reason why those timeouts are processed separately from timers and don't use timers facility. ScreenSavers used to be the only timeout and were coded before the general timeout mechanism was added; DPMS was kludged in on top of that mechanism. When the general timeout mechanism was added, the screen saver/DPMS code should have been migrated over. Yes, Ivan's patch fixed that. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: developer XFree86
Alex Constantine writes: I would like to participate Please check out this: http://www.xfree86.org/developer.html You can also find some info at http://xfree86.linuxwiki.org where I've started adding some development pages. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Fwd: 69030 driver
Rishabh Kumar Goel writes: Hi! Thanks for your suggestion. I tried that but nothing worked out. i am working on NetBSD. So i mapped the memory from 0xA to 0xB. From this memory mapped I tried to read a single byte from the device and also the word but of no use. I get only 0xFF. My first aim is to get the Green Light(LED) on the monitor to glow. How to get that thing. To explain to you every step that's required to make this happen would exceed the what I can provide to you here considering my limited time. There is a fully functional driver for this chipset in XFree86. Why don't you have a look there? It performs every step required to make happen what you want. We also have code to talk to the VGA memory aperture. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: Bryan W. Headley writes: As opposed to writing it to a log file. However keep in mind that what the X client opts to do with any such message(s) is up to that installation, including logging it to a file. But I'm thinking more along the lines of a) notifying the user with some dialog, or b) passing the message to the help desk through unknown mechanisms. (Email! :-) Sure, the client is free to do whatever it wants. b) send requests to external agents who can do things the X driver cannot. Example: Under Linux HID, you cannot program the HID device from its client API (e.g., no ioctls to switch from relative to absolute coordiantes) But it may be known that the kernel driver DOES support mode switching through other means (the ubiquitous procfs/sysfs) This is ugly. It could be done but then we'd have a linux only driver. If the HID interface would offer such things one could design a generic system interface with a OS dependent and an OS independent part. What I wanted to get across was the notion that the driver COULD initiate a conversation with a client of a very singular nature. Putting that into the API resolves any issues from people subverting other calls for their purposes. Regards generic system interface... we presently have several drivers that support different IO subsystems, and as a consequence are repeating code. Layers that I see are, o Datastream retrieval. E.g., is it RS-232, USB, Linux Input, Firewire? Such a layer needs to know the OS device entry, perhaps information on baud rate, etc. Highly reusable; we're talking about one set of binary per input type; one-to-many state objects (one per open connection) Yes. o Packet building. This would be input device/interface type specific. It would know that a packet of incoming data is 'x' bytes in length; it might understand that bit 4 is always set for synchronization purposes. It composes the hardware's packet into a generic packet, understood by, o Device Driver. The layer that understands that it's receiving input from a Wacom tablet; it's able to convert incoming packets into PostMotion events. Specific to the generic hardware product, but only requires a new packet builder to support a new input interface. I don't know if it is worth the trouble to separate the two latter ones. If I look at mice (which I've worked for recently) I see an opportunity to put in a generic post processing layer between the bare axis and button detection and the PostMotion/Button() call. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855 and 1400x1050
Thomas Winischhofer writes: So, why is 1024x600 sorted out on this machine then? (I ask because SiS BIOSes sometimes list wrong modes when probing, and refer to wrong internal modes numbers. I had hoped that Intel folks just forgot to change their probe function for this very machine and report 1024x600 instead of 1400x1050.) 1024x600 is a very unusual mode (I know of only one machine using it), what's the point in supporting this mode on a machine with a 1400x1050 panel?! That 1024x600 is listed desn't mean it's supported. You have to look for a '*' in front of the mode name. However it's strange that this funny mode is known to the BIOS however not 1400x1050. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: Bryan W. Headley writes: True, and that's a whole other set of problems. At least, in your example, everything is in the XI layer, if not in the individual driver. I'm more worried about an XI layer that talks to its drivers, but there's also a layer in Misc that does the same thing, but perhaps supercedes the XI layer, but all of that has been replaced by something in a third layer. No, not necessarily. If you take a look at the current xf86misc extensions they implement setting of some mouse parameters. Most of them are clearly related to mouse HW and are well separable form the XI view of things. That just illustrates the problem. Who would think to look at the Misc extension for that? I do. The point is: I'd opt a uniform concept to talk to the hw driver layer for all devices. There are other devices than just input devices. Correnly even the option handling of input drivers is different from graphics drivers. If possible these things should be made uniform. So what would you propose? Duplicate this in another extension or handling output drivers thu XI? Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855 and 1400x1050
Thomas Winischhofer writes: It is possible that the BIOS actually knows the mode, but has no VESA number for it. I have seen this at least on SiS hardware: SiS BIOSes maintain two mode number lists, one with internal mode numbers, one for VESA mode numbers. As the i810 BIOS, it has no VESA number for 1400x1050. With VESA VBIOS 3.x you don't need to have a VESA mode number. BIOSes assign their own numbers for non-VESA modes. You can query the BIOS for a list of modes and their properties. This list contains the mode numbers. BIOSes also list modes they know but don't support for various reasons (ie. not sufficient memory). Therefore you need to look for the supported flag. The i8xx driver does all that. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855 and 1400x1050
Alessandro Temil writes: Hoewever, I am absolutely astonished that the graphics BIOS on a 1400x1050 panel does not know how to set a 1400x1050 mode. That means, for example, that the kernel console driver could never set a mode that fills the panel. Does the i810 driver list the modes it got from the BIOS in the server log? I have a utility to read the BIOS mode list and display the results; I'll see if I can dig it up for you. It does list the modes, and it is common for modes matching panels like this to not be listed. It might be worth comparing it to the list you get when using the 'vesa' driver. Can someone with one of these laptops try that and post the results? David Here you are, i attached both i810 and vesa driver XFree86.0.log. (by the way, i'm new of this mailing list, if it doesn't allow messages with attachments i'll repost them inlined asap.) This moring i wrote to intel asking for the specifications, i hope to get a reply soon. Neither the VESA nor the i8xx driver lists any 1400x1050 mode. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: A lot of error conditions can only be fixed by the administrator. Can you come up with a really good real life example? I suppose 'Battery Low' would be one. That's the easiest one for everyone to grasp. Let's see: problems with the input device (it didn't accept programming/switch mode commands we asked for). I'm trying to think what would be a less-than-disasterous but still inconvenient situation for a video card to report... OK. That makes sense. However if your protocol supports mode setting you can implement this as the success status reported back. When you were talking about QoS messages I was thinking more of an event-type-of-thing. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: True, and that's a whole other set of problems. At least, in your example, everything is in the XI layer, if not in the individual driver. I'm more worried about an XI layer that talks to its drivers, but there's also a layer in Misc that does the same thing, but perhaps supercedes the XI layer, but all of that has been replaced by something in a third layer. No, not necessarily. If you take a look at the current xf86misc extensions they implement setting of some mouse parameters. Most of them are clearly related to mouse HW and are well separable form the XI view of things. How this will turn out in the end is probably not so much a matter of implementation but of discipline and coordination. Yes! But also documentation, both in terms of self-documenting code and the manuals in the ./doc directory. (Because, whoever looks at docs? :-) Right. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: Bryan W. Headley writes: Egbert Eich wrote: As you said a HID device is more or less unidirectional. Therefore you won't be able to detect from the device interface that something is wrong. The HID interface itself would have to provide QoS. Anyway QoS would not be part of XI but would be implemented in the HW messaging extension. Under Linux it is. Under BSD and Solaris (I think), you have read/write to USB devices. But if you do a read() from the device and the syscall errors out, that's an issue the X Driver can report. If the X driver expects relative coordinates but for some reason is receiving absolute coordinates, that's reason to issue a report. Are you sure? We'd have to check why the read would error out. It would do so if the device was closed because it was removed. That's a normal event when a device is hot pluggable. If XI supports removing of devices it would just notify the XClient of the removal. The coordinate issue is a device - driver compatibility problem. Do we want to report this to the client, or is it sufficient to tell the user about the problem in the log file. It *could* be a hotplug issue. But assume it's not: is it worth issuing a message somewhere? You say yes, because you'd put it in a log file somewhere. I agree, but think that giving the message the opportunity to pop up on a driver message monitoring app to be more enterprise friendly. One could argue that any serious condition that is reported in the log should also get reported by to interested clients. So far XFree86 doesn't know many such events. Most error conditons happen during startup where you have no option but to log them. My problem with log files is that they're generally put into a directory only the administrator can read. You've just made the product more expensive to support/maintain... A lot of error conditions can only be fixed by the administrator. Can you come up with a really good real life example? I suppose 'Battery Low' would be one. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: Your definition and mine are very similar. I would continue the definition to say that even intrinsic server functions, like loading a driver into memory, can be initiated by a client. Why? Because I would want to keep the actual server separate from these ancilliary functions. This is not how an X client works. X abstracts all these details from the client. The client should not have to deal with HW specific details at all. Certain exceptions to this rule make sense, I agree, but they must be considered carefully. Maybe I haven't understood what this is good for. Maybe it is just the confusion of terms. Darn! What I offered later in the mail thread you didn't see value in, either. I'll either have to send you to some white papers talking about other products doing QoS, or think of a better example for you... I did see the examples later in the message. So far X doesn't send QoS messages to the user. Most of the time these things are expected to be handled by the driver as good as it can. If it cannot handle them the condition is usually fatal anyway. Such things get recorded in the log file as this is something the 'administrator' will have to deal with. When a read returns unexpectedly this usually doesn't point to a problem the user can deal with. If somebody cuts the cable this would either result in a normal unplug event (in case of a USB device) with the result that the client will receive the message that the device has been unregistered or remain unnoticed altogether (serial device). I do understand the 'the battery in the cordless mouse is getting low' message. This would better live in the hardware messaging, ie. the successor of todays xf86misc extension. That's a different client than what I'm calling a client. OK, I should call my client an X-client. I don't think this needs to live in it's own thread. You have to open a /dev/something and listen for messages, don't you? No reason to have a separate thread there. Don't forget, the same select() loop also receives X events and you don't want the server to appear sluggish while dealing with non-core events. So yeah, spawning a thread to deal with them is not a bad idea. How much traffic do you expect? Right. That's what we need a registry for. I think your registry would know how to identify hardware and determine the correct drivers to load. But are you also suggesting that it knows how to ask the NVidia driver for its video resolution (e.g., it prefers a message in string format like, reso?, whereas the CT driver might use a different message?) That's why we need a registry. And I don't like string messages either. This is the current ad hoc implementiaton. Let's all get out the USB HID documentation and rip to pieces what's wrong/vague/ill considered in their teminology, then we'll have the beginnings of a wrong/vague etc., language for talking to drivers... OK, you want to start with the HW interface. Ah, no. HID tries to standardize hardware attributes for different devices into common terminology. Then they define standard messages for setting attributes and querying attributes from the hardware, given a standardized language. (Actually, enums) Their specs barely acknowledge that it's running on USB :-) OK. But it's the beginning of figuring out what attributes different types of hardware would have, and creating standardized terms for everything. (I believe) they made a few mistakes, but it's still something to learn from. OK. The XI needs to be entirely independent of this. It must abstract the entire HW if and needs to be generic enough to permit different HW interfaces. In prinicple both should be developed independently by different groups. Otherwise the XI X-client interface will be implemented too much along the OS specific HW interface. Completely agree. The X-client interface should only be concerned with the message format. OK. Cheers, Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: As you said a HID device is more or less unidirectional. Therefore you won't be able to detect from the device interface that something is wrong. The HID interface itself would have to provide QoS. Anyway QoS would not be part of XI but would be implemented in the HW messaging extension. Under Linux it is. Under BSD and Solaris (I think), you have read/write to USB devices. But if you do a read() from the device and the syscall errors out, that's an issue the X Driver can report. If the X driver expects relative coordinates but for some reason is receiving absolute coordinates, that's reason to issue a report. Are you sure? We'd have to check why the read would error out. It would do so if the device was closed because it was removed. That's a normal event when a device is hot pluggable. If XI supports removing of devices it would just notify the XClient of the removal. The coordinate issue is a device - driver compatibility problem. Do we want to report this to the client, or is it sufficient to tell the user about the problem in the log file. And yes, the kernel device driver can also issues quality of service reports. In the kernel's case, there's no-one that you can specifically send reports to. With my kernel device driver, I have a diagnostic file in the procfs that something could monitor for complaints... Do you have to obtain this information from a dedicated diagnostics file, couldn't you read it from the general kernel log? I do understand QoS notifications where one deals with frequently occuring conditions that require rapid action - like battery low information, but all cases of software of hardware failure are exceptional incidences that would be sufficient to log. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Mike A. Harris writes: Doesn't the following CVS commits implement such an API? Yes, although I don't like the implementation. It requires that the client knows the exact details of a particular driver. This should be replaced by something that provides more information on the particular type of configuration data. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Maybe not everything... Some things only make sense at server startup, but yes, I want to make things configurable on the fly - but using another extension, not XI. Correct. My outlook is a more generic client -- driver API (remember I use the word client very loosely -- it could be the parse XF86Config file, tell drivers to load into memory, and configure yourself to XXX client. Because face it, what's unique about an input device that it needs a special status-reporting, state-setting, loading/unloading self to hotplug events API? Well, maybe we should first define the word 'client' so we are sure to talk about the same thing. When I say 'cleint' I mean X client (ie. any application connecting to the server thru the protocol). 2) a QoS layer, that the driver can use to initiate it's own messages to unknown listeners. I keep losing you on this one. Am I losing you on the concept, or the usefulness? Maybe I haven't understood what this is good for. Maybe it is just the confusion of terms. Yes, that would be a radical change in input driver design. You'd have some dummy agent which knows about the available driver, waits for hotplug messages and just load the appropiate driver. This however is quite independent of the XI extension (apart from generating events that a new device has arrived.) That's correct. A device manager component of the X Server, which I would call a client because it's likely executing in it's own thread, which gets messages from the OS and tells drivers to load/unload theirselves. It also poses a security risk, and now there has to be an understanding over who is sending said messages, and what that person is capable of asking for. That's a different client than what I'm calling a client. OK, I should call my client an X-client. I don't think this needs to live in it's own thread. You have to open a /dev/something and listen for messages, don't you? No reason to have a separate thread there. Not user customizable. But definalbe by each individual driver. Of course. But if you're asking drivers questions without knowing/caring what type of driver it is, you'll need some sort of standard vocabulary. Right. That's what we need a registry for. If we're talking about driver configuration, the drivers DO control what the option names are with impunity. The only reason why there isn't total chaos is because there is a finite number of terms you can call options, and we tend to look at each others' work right. But if there was an API where you can ask standardized questions of any device driver, e.g., what's the resolution along the x-axis, what would be the keyword you use? xResolution? Good, except the number of axes are up to about 7 on input tablets (x, y, z, pen tilt on x y, pen rotation, wheel). And the units of measurement need to be expressed, coming back. A monitor would talk about dot pitch (not neccesarily caring about the resolution it's video card is driving it at); the input device would talk about coordinates per inch/mm. I'm trying to remember what Mickeys meant, in terms of mouse movement... My favorite sick question to ask a video driver is, if you're implementing translucence, what's the simulated Z coordinate's resolution? (And because it's simulated NOW, what makes you think it's uniform across the entire area of display) Let's all get out the USB HID documentation and rip to pieces what's wrong/vague/ill considered in their teminology, then we'll have the beginnings of a wrong/vague etc., language for talking to drivers... :-) OK, you want to start with the HW interface. The XI needs to be entirely independent of this. It must abstract the entire HW if and needs to be generic enough to permit different HW interfaces. In prinicple both should be developed independently by different groups. Otherwise the XI X-client interface will be implemented too much along the OS specific HW interface. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Sorry, just telling you how it is, now. hotplug listens to a kernel message layer, and invokes shell scripts in response to events. These scripts can load/unload kernel device drivers, mount discs, etc. All these things would do is write a message to some kind of listener in X. Said listener would be an application... Architecting it any other way would put us very close to the Linux kernel and hard to abstract to other operating system implementations. I come from a messaging middleware background, so I'd prefer some kind of messaging API that clients who have interest would listen to, and receive plug/unplug messages. But Linux hotplug can't do it that way, because the components it deals with only understand command line invocation and reinvocation (e.g., insmod is a command line utility, not a daemon) What makes hotplug interesting (both in a good and bad way) is that it has a flat file database of USB productId/vendorIds and the driver(s) to load. The kernel also has a list of devices, more along the lines of these devices have quirks, and the normal algorithm for determining which device driver to assign to the hardware won't work... let individual drivers ''grab'' these devices, if they are found. Department of redundency department... :-) Knowing that the device has a USB id and using that on our side to keep a database of XFree drivers is a little shortsighted; for example, I don't know what USB will be replaced with next year, and what it'll use for it's identification. Also, with the Aiptek tablets, there happen to be 6 separate IDs that match to the kernel driver, as well as several clones. So the id becomes something like, Aiptek-like, or Wacom-like. And just because I'm into fun, let me advise you that /dev/input/event2, which might be the device that the tablet's currently mapped to, is highly changeable. In other words, the tablet may be event2 today, but under the same configuration, the kernel decides to map it to event1 tomorrow. And if I plug/unplug the tablet, all bets are off. Why is that? Because the Linux Input system creates pseudo driver entries: these names have no correlation to the actual connector the physical device is connected to, e.g., /dev/tty02... Yes, that's a different issue which can happen to you with usb mice and keyboards, too. This needs to be addressed. The point is, the device driver 'mount point' (/dev/whatever) no longer uniquely identifies a device. I wonder about it's continued exclusive use in XF86Config. I further wonder what the best replacement should be... 1) the current struct layouts are pretty restrictive. 2) I'd like to query an individual driver for it's feedback. 3) I'd like for a driver to be capable of initiating a conversation. For example, to send quality-of-service messages (hey! I keep erroring out on this select() call -- has the device been unplugged again?!?) The purpose of the XI extension was an abstraction of all that from the client. We learn that such an abstraction is not always possible - that some HW features should be configurable while the server is running. The question is if this should be done thru the XI extension or thru another extension (a revised form of the xf86misc extension) which exposes the driver's view of devices rather than the logical view of the XI extension. I don't quite understand what you are referring to in 3). The driver is free to do any conversation with the HW (or kernel IFs) it requires. This conversation should be abstracted away from the client, though. No, it isn't. The Linux Input device layer is unidirectional: you listen to the tablet, and that's it. There are some ioctl calls you can make to determine the OEM name of the input device, and read capacities, but that's it. But that's not what I was referring to, anyway. QoS, or quality of service, allows the system to send heartbeat messages, or panic messages when things go awry. A message monitor collates these messages and acts on them. For example, a read() from the device fails; the XFree driver sends a QoS message saying hey!; a pop-up appears asking the user if they've cut the wire to their mouse... As you said a HID device is more or less unidirectional. Therefore you won't be able to detect from the device interface that something is wrong. The HID interface itself would have to provide QoS. Anyway QoS would not be part of XI but would be implemented in the HW messaging extension. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: David Dawes wrote: On Fri, Aug 29, 2003 at 02:28:13PM -0400, Joe Krahn wrote: I've discussed XINPUT before, tried to fix some things, and realized that the XFree86 XINPUT code needs a complete re-write. It is particularly messed up for non-pointer devices. Jim Gettys took over XFree86 XINPUT, and agreed that a re-write is needed. I put off working on XINPUT until he got started, because he knows much more about X than me. I've been busy doing other things, so I don't know what the recent progress is in updating XINPUT. As a general rule it's usually not a good idea to use the possibility that someone else might be working on something as a reason to delay starting on it yourself. Unless, that is, you're in the loop with what is happening. I got caught out on this myself regarding functionality simliar to RandR a couple of years ago :-(. No but you don't want to be a jerk and compete with somebody else. As if there were enough developers to go around that we'd steal each other's projects :-) If you know that somebody is interested in this you should get in touch with him. Maybe he can contribute to the discusson but has no time to look at the implementation. If he is even too busy to contribute ideas to the discussion the person may not be able to get to this topic in the near future anyway. I'm not aware of anyone currently working on a rewrite of the X Input extension for XFree86. Now would be a good time for someone who is to speak up. Otherwise the discussions here should continue with the goal of solidifying how a new version of the input extension for XFree86 should look. I dropped Jim Gettys a note, asking him about his involvement with XInput. If he's not working on it anymore, maybe he can pass some of his ideas and we can incorporate that. And if he is, great. The more the merrier. Right. I don't know about taking on the whole layer, but I'm definately going to write a 'feedback' API that's bidirectional and will accept an array of Atoms/values. I still think there's synergy between that and the XF86Config parser. E.g., the same mechanism can deliver XF86OptionRec's, and the xf86findOptionXXX API can be reused on the driver's side. That way, initial driver load/configuration, configuration query, reconfiguration could rely on the same parsing API, and you're no longer exclusively tied to XF86Config files You should abstract yourself more form XF86Config when you do this. I definitely would not use the same parsing API. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Rafa³ Rzepecki writes: On Thursday 28 of August 2003 17:59, Egbert Eich wrote: Sure. What we should probably do now is to get in touch with all interested parties to get their input. We must make sure we don't jump too short again. A generalized API for passing messages to and from the driver (to userspace and back) would be more than useful. It would serve as a way to implement device-specific features, requiring specialized client support without losing the generic features that all the apps could use. In the very early days of [EMAIL PROTECTED] Sven Luther and I discussed something like this. Eventually this discussion faded out in the heat of these days For example I could use this API in communicating battery and RF channel status of my cordless mouse to a client and sending RF channel switching requests. A client-driver communication is neccessary here, because a user would want to know the battery level at any given moment, and also be able to switch the channel whenever xe likes to. Right. Few drivers do such things now, but using weird tricks (vide XLedFeedback in citron or shared memory in synaptics). Yes, many of those 'tricks' may actually introduce security holes. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Claus Matthiesen writes: Actually, I'm really getting into the idea that the device can sort of tell the application how to interpret its data. I'll elaborate later in the mail... OK. You may want to 'bind' one tablet to one application and the other one to another appication. I don't know if this would be any useful. You could use the same stylus on both tablets (if both tablets can use this styles) and then it would appear as a different device. The tablet itself however doesn't have to appear at all - as you said. As I was trying to find some clever way of making a general structure without using a hierachy, I realized that that probably is the easiest, most future-secure way of doing it. Alright, you convinced me. ;-) Yes. But with the wide range of input devices how unified can this be? You can always treat something generically - but you will be missing some of the device dependend features. This is semi-correct. Which means that it's correct unless you're very careful when you design it. But we're being careful, aren't we? Again, I'll elaborate later on the flexible API I'm thinking of later... Hm, I bet when the current XI was designed it was considered flexible, too. Both a connect and disconnect event. When somebody brings in a new pen you want to know about this. Removing a pen is more difficult. This can only happen when the tablet is unhooked. It might be because I'm unfamiliar with X's inner workings but I don't understand those last two sentences... Why is removing a pen more difficult? I may have been imprecise. You can register a pen that hasn't been seen before by bringing it close to the tablet so that the tablet detects it. You cannot remove a pen once it is moved out of the proximity of the tablet. Only if the tablet itself is unhooked (or otherwise unregistered) you must forget all its devices. Joystics? Foreced feedback devices? Non of those have been addressed so far. Everybody seems to be talking directly to the kernel interface. Ah - force feedback! That even requires information to trickle back along the pathfrom the API into the driver and back to the device. Good point. e) Device ID identification. You may want to add properties to a certain pen so that when you use this pen it behaves in a certain way. Therefore you must be able to uniquely identify the pen. Yes! I definitely need that urgently too. Sure. What we should probably do now is to get in touch with all interested parties to get their input. We must make sure we don't jump too short again. Precisely. Who are the interested parties? And why aren't they reading this mailing list - or, is they are, coming with any input? That's a good question. Partly because some still consider this mailing list being focussed on graphics hardware issues? The GUI folks are not very interested in this. There is another mailing list [EMAIL PROTECTED] which was established to communicate with those groups that are building on top of X. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: Claus Matthiesen writes: Let's just forget about expanding the _XDeviceInfo struct for a minute and just concentrate on the -type field. Because as regards legacy software: Does anybody use the -type field? I don't want to change the -name, that's fine as it is and that's what most people use now as I understand it. It's the -type field that bugs me because the documentation actually says it should return the information I want - it just doesn't. I just seem to remeber that the type field is used in the wrong way by the driver. Some seem to make their own atoms instead of using the predefined ones. Actually, we don't need to re-open the driver as such. If you plug the tablet in again, can't we just pretend it's a brand new tablet and that the old one just died and went away? If we don't look for the tablet but for the pens we may even be able to reidentify the pens by their IDs. Not all tablets support pen IDs but some seem to do. At which point, you might as go the extra steps that MY private API has, which allows the client to change ANY parameter of the device driver that could be specified in the XF86Config file, while the driver is running... ...which is a good thing. We should just make a unified API for it. The problem is that there is no decend way to communicate this information to the server yet. Heh. In my spare time, I'll put something together. But things of value that I'm looking at, 1) A layer that can configure/inspect the driver (e.g., it handles everything in the XF86Config file, bidirectionally). Which fits right into making that puppy modular/enterprise controllable. Maybe not everything... Some things only make sense at server startup, but yes, I want to make things configurable on the fly - but using another extension, not XI. 2) a QoS layer, that the driver can use to initiate it's own messages to unknown listeners. ? 3) An external event interface. Basically your hotplug events, although I'd like to extend that to supporting a conversation like, well, a tablet's now plugged in; you have no tablet drivers loaded now. The tablet's identified by 'blahblahblah'. Figure out which driver that corresponds to, load yourself with default settings Yes, that would be a radical change in input driver design. You'd have some dummy agent which knows about the available driver, waits for hotplug messages and just load the appropiate driver. This however is quite independent of the XI extension (apart from generating events that a new device has arrived.) 4) Then, some level of user-customizable API. E.g., all parameters have names that are converted to Atoms, whose values are type-safely converted back and forth. Gad, it sounds like SOAP / XML/RPC! Maybe it is... Not user customizable. But definalbe by each individual driver. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: New device handling in X (was: XInput: The device type inXListInputDevices comes up again...)
Claus Matthiesen writes: This is a summation of the discussion between the est. Bryan W. Headley, the est. Egbert Eich and myself so far, along with a few new ideas... OK. Most people seem to think we need a new way to do device handling of what is currently called extended devices in X. I, as an applications programmer, find that it is far too restrictive and very importantly that the device drivers written for it do not sufficiently conform to the documentation, and the device programmers find that it cannot express all the aspects of a modern Human Input Device (or HID). There are two choices: Either to fix the old broken API or to make something new and phase the old API out. In favor of fixing the old API is the fact that making a new one would mean going over every driver to make them conform to the new API. This is a large task. Besides, people know the old API. We need to keep compatibility to the old API, which means when a client with an earlier version connects we'd have to deliver the events of the old API. Therefore keeping what is OK about the old API actually makes a lot of sense. I need to think a little bit more about your ideas. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Claus Matthiesen writes: Exactly. Sort of guessing on the basis of a string which might contain this or that isn't good enough for industrial strength software which we all agree should be able to run under Linux/XFree. But unless I am much mistaken, there is *no other* way of finding out which kind of device one's got ones hands on - please correct me if I'm wrong, because that's what I need... Unfortunately no. What we probably need is a Registry for known devices. However the naming sceme needs to be generic enough to also hold enough information so that if a device is not known to an application that the application can do something useful with it. you make an Atom, call it XI_STYLUS, etc., and mess you up, because you'd hardly be expected to know that a XI_STYLUS is related to a tablet But do you really need to know that? Isn't it enough to know it's a stylus? If you've got two tablets (which after all must be a bit rare) do you care, either from the applications or the users point of view, which tablet is used with which stylus? (I am here ignoring the fact that the stylae must physically work with the tablets of course) As far as I understand it (without being an expert on tablets) the fact that there's a tablet is rather uninteresting. You may want to 'bind' one tablet to one application and the other one to another appication. I don't know if this would be any useful. You could use the same stylus on both tablets (if both tablets can use this styles) and then it would appear as a different device. The tablet itself however doesn't have to appear at all - as you said. (that's sort of localized knowledge to the given device being supported). The term 'tablet' is inconclusive. XI_TABLET should not be used for such tablets. I can argue both for and against that statement. Don't forget, the application using the API possibly will want to indicate the pen device #1, #2 and mouse device #3 are all related to a tablet, in the spirit of user-friendliness. ...and if that's really useful knowledge, what you're saying is that we need some sort of grouping of devices. Well, I can go along with that... Or a hirachy. Input devices are a rather wide area. I have difficulties to overlook what all may be required, but when we extend the XInput extension we must be careful not to impose limits like the old one did. The tablet itself is not really the device as far as XI is concerned. It does not provide coordinates/keys/buttons itself. Yes it is but no it isn't. Remember, there is a single cable running from the tablet to the USB port. Which means, if it's hotplug disabled, somebody has to understand that all these devices should be disabled... But if stylus, cursor and eraser are all registered as unique devices, won't that just mean that for every registered device we get a message that it's been unplugged? It can't be a problem to disable all the devices which are plugged into the tablet within X itself when the tablet is unplugged or switched off and then X just needs to tell me as an application programmer that each of these devices - the stylus, eraser, etc. - have been disabled... Yes. Ideally, shouldn't the _XDeviceInfo struct contain some sort of information about how to decode the information in the events one receives from the device? It's certainly not very elegant if it's necessary to have the program explicitly know which tablet the driver is running. The whole point of a driver is to have a unified interface. If there's something this interface can't express then it's a problem with the interface and it must be changed or expanded. Yes. But with the wide range of input devices how unified can this be? You can always treat something generically - but you will be missing some of the device dependend features. These would be properties. Properties can be accumulated, types are exclusive. I don't know if we can manage to characterize all device properties completely and if this is desirable. In many cases we may just be able to supply coordinates and the application needs to be configured to know what to do with these. A heirarchical system is the way to go. Well - isn't that an overkill? So far the only thing that's come up as a problem is a tablet and that has only one level of hierachy which is even a bit contorted since the highest level in the hierachy - the tablet - doesn't produce events while the lower level - stylus, eraser, etc. - does. It may or may not be. Input devices are not tablets only. Summation: a) Can't every device attached to a tablet just become an independent device in X, so that one can ask for an XI_CURSOR, XI_STYLUS or XI_ERASER? We might expand the _XDeviceInfo struct to contain information about grouping if that's desired. This could be implemented quite
Re: XInput: The device type in XListInputDevices comes up again...
Claus Matthiesen writes: Let's just forget about expanding the _XDeviceInfo struct for a minute and just concentrate on the -type field. Because as regards legacy software: Does anybody use the -type field? I don't want to change the -name, that's fine as it is and that's what most people use now as I understand it. It's the -type field that bugs me because the documentation actually says it should return the information I want - it just doesn't. I just seem to remeber that the type field is used in the wrong way by the driver. Some seem to make their own atoms instead of using the predefined ones. Actually, we don't need to re-open the driver as such. If you plug the tablet in again, can't we just pretend it's a brand new tablet and that the old one just died and went away? If we don't look for the tablet but for the pens we may even be able to reidentify the pens by their IDs. Not all tablets support pen IDs but some seem to do. At which point, you might as go the extra steps that MY private API has, which allows the client to change ANY parameter of the device driver that could be specified in the XF86Config file, while the driver is running... ...which is a good thing. We should just make a unified API for it. The problem is that there is no decend way to communicate this information to the server yet. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
Hi John, thanks on following up on this. John Dennis writes: Anytime in the XServer when MMIO was specified as a mapping flag the ia64 code would have requested non-cached, this is done for all register mappings and the VGA framebuffer (because write combining was avoided on banked memory). Appearantly there are still issues with VGA framebuffer and emulated PIO register writes when saving and restoring fonts. These problems only affect certain cards (so far I've only heared of Nvidia cards). Mark Vojkovich is sure that these are related to caching problems, too. Have you made any progress investigating this issue? Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
John Dennis writes: I will confess my understanding is weak when it comes to low level bus interactions, but I'm learning more eveytime I have to tackle these issues ;-) Correct me if I'm wrong, but I thought things like caching and write-combining are not properties of the PCI device, rather they are properties of the memory system upstream of the PCI device, e.g. bridges, memory controllers, and the MMU in the CPU. Right. The PCI configuration does provide various pieces of information which help determine how the device can be accessed, e.g. pre-fetch, latency, cache line size etc. All of this is available to firmware. Wouldn't all this be sufficient for firmware to make the right decisions? That's what I would like to know. I was hoping our contacts to HW vendors would provide us answers to these questions. Some of these questions seemed to have been answered in one of your previous posts - at least as far as HP's IA64 boxes are concerend. The chipset simply definces *all* IO (access to PCI buses) as uncached. So nobody bothers to derive such properties from information provided by the PCI devices. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: That is correct. However Claus was talking about the future - once that is fixed. Appearantly toolkits like gnome already do make use of the name field. Sure, albeit dangerously. They had best not be making decisions based on what's returned in the string... Yes, to some extend. The app would have to know the exact string used in the driver. Let's talk about tablets: tablets CAN support separate pointers concurrently. On the wacom and my aiptek driver, you can have a cursor, a stylus and an eraser. They are mapped into individual XFree devices, pseudo-devices, because they all share the same file descriptor (of course they do: all inputs come in from the same OS device). Now, if you want to relate that this device is somehow a tablet, you set type to XI_TABLET (but you loose the ability to easily determine if the inputs from a cursor, stylus, eraser.) So, if you decide that's more important, you make an Atom, call it XI_STYLUS, etc., and mess you up, because you'd hardly be expected to know that a XI_STYLUS is related to a tablet (that's sort of localized knowledge to the given device being supported). The term 'tablet' is inconclusive. XI_TABLET should not be used for such tablets. I can argue both for and against that statement. Don't forget, the application using the API possibly will want to indicate the pen device #1, #2 and mouse device #3 are all related to a tablet, in the spirit of user-friendliness. Right. If we want that we'd need some kind of device hirachy. The tablet itself is not really the device as far as XI is concerned. It does not provide coordinates/keys/buttons itself. Yes it is but no it isn't. Remember, there is a single cable running from the tablet to the USB port. Which means, if it's hotplug disabled, somebody has to understand that all these devices should be disabled... Right, the driver knows and can mark all devices (ie. styluses etc) that depend on this cable as disabled. The application has a different view on things than the driver has. Most do not. Mine does, because it's the client side of that client/driver API I mentioned: it has to know which drivers support my extended API. But I don't expect to find that kind of info in the deviceInfo struct... Right. There are simply too many possibilities. So you'd have to teach the client which valuator, axis, key, or button does what. These would be properties. Properties can be accumulated, types are exclusive. I don't know if we can manage to characterize all device properties completely and if this is desirable. In many cases we may just be able to supply coordinates and the application needs to be configured to know what to do with these. A heirarchical system is the way to go. Are you talking about a hirachy for the devices or for the device properties? Yes, I also came to the conclusion that we may need a device hirachy. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: cvs:drivers/via/via_driver.c: problem with Virtual
death writes: The Savage driver, from which I believe this driver was derived, copies pScrn- display-virtual[XY] to pScrn-virtual[XY] a page or so above the call to xf86ValidateModes. Is that not happening here? -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. Well, i hadnt looked as far, i just saw it done like this in vesa.c and i810_driver.c. Also, i just used a few xf86DrvMsgs to tell me the values of pScrn-VirtualX/Y throughout PreInit. In both vesa and via_driver, they were 0 before xf86ValidateModes and set (properly in case of vesa and to actual resolution in via) after. This made me assume that pScrn-display-virtualX/Y would contain the values of the Display subsection, the values requested through the config and that xf86ValidateModes would validate this (duh.) and, if approved of, place those values in the toplevel pScrn. Yes, this should be done in xf86ValidateModes() and in fact the via driver doesn't copy it before calling it. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
Marc Aurele La France writes: On Tue, 26 Aug 2003, Egbert Eich wrote: Frankly, I don't see how this EFI MDT can be accurate given that, in general, whether or not a particular PCI memory assignment will tolerate caching and/or write-combining is highly device-specific. That would be a horrific PCI device database for EFI to maintain. How that is done is in fact an interesting question. Maybe someone with good contacts to HP could inquire on this. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes:
[EMAIL PROTECTED] wrote:
{
_XDeviceInfo* device_list = XListInputDevices(display, n);
if (device_list[a].type == XInternAtom(display, XI_TABLET, true))
{
printf(Device %s is a tablet, device_list[a].name);
}
}
Now I have two questions:
a) Should a device's type be tested in the above way once the fix Egbert
suggested has been implemented? I do hope so since it makes the most
sense...
No.
The problem is, there's a type field and a name field. They're not
populated consistently by all drivers, and the fields are not sufficient
to accurately describe the device, anyway.
That is correct. However Claus was talking about the future - once
that is fixed. Appearantly toolkits like gnome already do make use
of the name field.
Let's talk about tablets: tablets CAN support separate pointers
concurrently. On the wacom and my aiptek driver, you can have a cursor,
a stylus and an eraser. They are mapped into individual XFree devices,
pseudo-devices, because they all share the same file descriptor (of
course they do: all inputs come in from the same OS device). Now, if you
want to relate that this device is somehow a tablet, you set type to
XI_TABLET (but you loose the ability to easily determine if the inputs
from a cursor, stylus, eraser.) So, if you decide that's more important,
you make an Atom, call it XI_STYLUS, etc., and mess you up, because
you'd hardly be expected to know that a XI_STYLUS is related to a tablet
(that's sort of localized knowledge to the given device being supported).
The term 'tablet' is inconclusive. XI_TABLET should not be used for such
tablets. The tablet itself is not really the device as far as XI is
concerned. It does not provide coordinates/keys/buttons itself. That
would be like saying your mousepad is your input device. Instead each
pen should be considered a different input device and we may need to
extend the list of predefined types to accomodate those.
I don't really know if it is at all importand that different pens are
related to a specific tablet. If it is we need a way to 'group'
certain devices together.
Now, you have the name field. What do you put in there? Lots of people
put in the name of the device driver. E.g., aiptek or wacom stylus.
This doesn't help the USER, because that's not the identifier he used in
the XF86Config file.
Now, I personally have reasons for wanting to know that a given device
is supported by my device driver: I have a client/driver API layered on
top of the FeedbackControl API. What do I do? Assume because I support a
tablet, that all tablet's found are obviously controlled by my driver
(wrong!) Assume that if I find a XI_CURSOR, it's obviously something
that belongs to my driver? (wrong! the user could have two tablets, one
of which is a wacom...) Do something to the name field to pass three
pieces of information? (e.g., you used the identifier Leopold for the
stylus pseudo device driver, that's controlled by the aiptek driver, so
perhaps Leopod (aiptek:cursor)? That's not real user-friendly. Does
that mean that your app should know to only display the first word of
the name field? Ugh...
What I'd like, but haven't started an in-depth search for in the API:
given a deviceInfo struct, I'd like to learn the device driver name
associated with the device.
The device driver is completely irrelevant to the application.
Why should the application know that? The application may want
to know a vendor string and an ID to know more about the properties
of an individual device (some pens supply pressure or angular data
some don't).
What I think is needed, but I don't know if this is sufficient: a device
type and sub-type, which are both Atoms and codified so a user app
actually has a chance of understanding what the string sequence means.
But is a single sub-type sufficient? I don't know. For example, Data
Gloves: is it important to know that it's left or right-handed? Can
those have styluses, too? Then that's two sub-types. Is it possible to
have more?
These would be properties. Properties can be accumulated, types are
exclusive. I don't know if we can manage to characterize all device
properties completely and if this is desirable. In many cases we may
just be able to supply coordinates and the application needs to be
configured to know what to do with these.
Egbert.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: cvs:drivers/via/via_driver.c: problem with Virtual
Committed. death writes: Seperate modelines error out on: width too large for virtual size for everything since this virtual width then is 0. Virtual config does not work, max/default usable size is used instead. Reason: via_driver.c:VIAPreInit: xf86ValidateModes is called with pScrn-virtual[XY] instead of pScrn-display-virtual[XY] This looks like a plain oversight from via which has existed since 1.1. and is pretty trivial. Thanks, Luc Verhaegen --- xc/programs/Xserver/hw/xfree86/drivers/via/via_driver.c 2003-08-25 04:05:39.0 +0200 +++ xc1/programs/Xserver/hw/xfree86/drivers/via/via_driver.c 2003-08-25 04:05:39.0 +0200 @@ -1504,8 +1504,8 @@ 16 * pScrn-bitsPerPixel, /* pitch inc (bits) */ 128, /* min height */ 2048, /* max height */ - pScrn-virtualX, /* virtual width */ - pScrn-virtualY, /* virutal height */ + pScrn-display-virtualX, /* virtual width */ + pScrn-display-virtualY, /* virtual height */ pVia-videoRambytes, /* size of video memory */ LOOKUP_BEST_REFRESH); /* lookup mode flags */ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Static server build problems in via driver
Egbert Eich writes: David Dawes writes: Is the static build problem likely to be fixed before Monday's snapshot? I doubt it. I'm quite overloaded with work. I was going to merge in the latest patch however I had conflicts applying it. I need to investigate some more. Maybe I get to it later today. OK. I've committed the latest patches and fixed the static build. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DPI with multiple heads and virtual desktops
Dr Andrew C Aitchison writes: Are you sure you actually want the problem solved anyway ? We have a laptop with a 125dpi screen and a lecture room projector with about 8dpi. If I were to make it run a two screen desktop, and my slide viewer honoured the true screen DPI, on one screen 12pt letters would be 20 pixels tall, and on the other they would be about one pixel. This illustrates how useless the screen size is to determine the 'felt' DPI ie. the resolution the user really feels. To calculate this value (and that is what should really matter) we have to make a number of assumptions: 1. The user adjusts his display so that he can view it comfortably, that is he places it at a distance to his eyes that he can view the entire screen without head and with very little eye movement. 2. There is a certain horizontal and vertical angle within which objects appear sharp and with sufficient details to the human eye. If we review literature about workplace ergonomy we may find an average value for these vision angles. 3. When we read (from paper) we adjust the paper so that it is at a comfortable viewing distance. If we place it closer to our eyes it will overstrain the muscles that focus the lense if we place it too far away the text will become too hard to read. For all people with normal sight (or using corrective devices to restore normal sight) this distance is approximately the same. There should be more or less agreed upon value in literature also. 4. When we view a document on the computer screen we want it to appear at approximately the same vision angle as we read the same document from paper. Using assumption 2. and 3. we can calculate the size of the vision field at the 'comfortable reading distance': q_h, q_v := horizontal/vertical vision angle d := 'comfortable' reading distance h,v := horizontal/vertical dimension of vision field h = 2 * d * tan(q_h/2) v = 2 * d * tan(q_v/2) From assumption 1 and 4 it is immediately clear that to obtain a roughly equal viewing angle for documents viewed on the computer screen and on paper we need to use these values to determine the DPI. The horizontal/vertical display ratio of a computer screen is approximately 4/3 in most cases. Assuming that h/v 4/3 Therefore the vertical screen size will determine the distance of the screen to the eyes. With: D_h, D_v := horizontal/vertical size of the computer screen we can therefore calculate the 'felt' screen dimensions like: v_s = v h_s = v * D_h / D_v Applications are passed the screen dimensions and the virtual pixel dimensions. Thus we should correct the screen sizes passed to the application: To do this we can either use the physical pixel size used at server startup time or the one that's used at the time the application is started. With: r_h, r_v := physical pixel size r_h_virt, r_v_virt := pixel size of the virtual screen v_s' = v_s * r_v_virt / r_v h_s' = h_s * r_h_virt / r_h These should be the screen dimension values passed in the connection block. So far we have dealt with idnividual screens. The Xinerama case needs to be treated a little differently. The personal preferences of the user may deviate from the 'normed' values of the viewing angles and comfortable reading distance. Furthermore the user may want only a portion of the screen to appear in his 'viewing area'. Since all relationships above are linear a single scaling factor Will suffice to allow the user to adjust things for is personal preferences. XINERAMA Here we must distinguish two uses: 1. The desktop 2. The video wall 1. Desktop == Xinerama knows abbout a single rectangle screen with no holes. It therefore doesn't make much sense to combine screens with different resolutions as the screen will contain unviewable areas. We should also assume that the user uses displays of similar physical dimensions or at least places the displays in a way that he can view them under the same viewing angle. At the same time we assume that the user views an application window on a single screen. To view windows on the other screen the user will move his eyes or head. Therefore the calculated resolution should be the same as the one of a single head. We therefore need to 'rescale' the screen dimensions passed in the connection block: With r_h_virt, r_v_virt := pixel size of the Xinerama virtual screen r_h_virt1, r_v_virt1 := pixel size of the virtual screen of the first head we get: v_s'' = v_s' * r_v_virt / r_v_virt1 h_s'' = h_s' * r_h_virt / r_h_virt1 2. Video Wall = As the viewer is expected to view the entire screen at once the calculation is similar to the single desktop. To calculate the 'felt' horizontal dimension one needs to obtain D_h and D_v. if we assume that identical screens are used with the virtual pixel size equal to the physical size desktops are used we can do: D_h = D_h_1 * r_h_virt1 / r_h_virt D_v = D_v_1
Re: vfb port to xf86 device driver interface
Mark McLoughlin writes: Hi Alan, My impression was that the purpose of the dummy driver was a skeletal implementation of a device driver which people could use when writing new drivers. That's what I used if for anyway :-) Not really. It is a fully working driver. I wrote it to simulate a 4x4 head display with just two real cards. The intention was to add the headless and input device-less support from Xvfb along with the ability to undump the output using xwud. I suppose I could have done that with the dummy driver, but that would negate its value as a skeletal implementation ... It takes care or the headless stuff. The input device handling can be handled by the 'void' input driver. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: vfb port to xf86 device driver interface
David Dawes writes: On Fri, Aug 22, 2003 at 02:42:55PM +0100, Mark McLoughlin wrote: Hi Alan, My impression was that the purpose of the dummy driver was a skeletal implementation of a device driver which people could use when writing new drivers. That's what I used if for anyway :-) I thought its purpose was to be a hardware-less driver that could be used to simulate/test multi-head configurations without having lots of video cards. But Egbert, as its author, would be best placed to provide the definitive answer :-). Exactly. Harald Koenig and I did a show with a 4x4 head display with 16 S3 Savage4 chips. I saw rendering issues there which I never saw with a single card. Of couse when I was back in my development environment I didn't have the 16 chips and FPs any more so I had to find another way to simulate this. The driver was rather simple to do. After all I did not have to deal with mode settings ;-) What is it missing as a skeletal implementation is some of the bus-related code that a typical real driver would need. The intention was to add the headless and input device-less support from Xvfb along with the ability to undump the output using xwud. I suppose I could have done that with the dummy driver, but that would negate its value as a skeletal implementation ... I'd suggest that a sample or skeletal example be called sample or skeleton. There is an input driver called sample that was The DESIGN document contains a skeletal driver. That's why nobody ever bothered to create a separate 'skeleton'. Both would have to be kept in sync. intended to be a reference for writing input drivers. It was out of date for a long time, and I'm not sure of its current status. There's also an input driver called 'void', which is kinda like the 'dummy' video driver. It is used to satisfy the requirement of having both a core pointer and keyboard, without using a physical device for one or both. Right, the void driver is just the input counterpart. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA and banked memory
Mark Vojkovich writes: XAA itself doesn't care. You set the LINEAR_FRAMEBUFFER in the XaaInfoRec Flags if you have a linear framebuffer. If you don't set that flag it won't put pixmaps in offscreen memory (because the software rendering code won't be able to deal with them), and it won't use an offscreen pixmap cache for the same reason unless you provide XAA's ImageWrite, WritePixmap or WritePixmapToCache replacement functions. The most difficult part of banked framebuffers is the software fallback code. I'm not sure what the status on the banking layer is. Marc La France would know. The banking layer doesn't have RENDER support. Apart from that it works well. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: autotooling xrandr
Warren Turkal writes: Is there any chance of upstream acceptance of this type of work? A lot of the utility binaries should be pretty easy to break out the xc hierarchy. This issue is coming up from time to time and I have jet failed to understand the benefit of breaking out things out of the xc hirachy. In fact I can think of a very few things where this may be worthwhile doing. Applications: You can roughly split applications into three groups: 1. system/query: xvidtune, xdpyinfo, xlsfonts, xfd ... 2. applications: xterm, xedit... 3. minor apps/toys: xeyes, oclock, xclock, xcalc ... I would say 1. needs to be shipped with the server core. xrandr belongs in there, too. Most of these apps are meant to either allow for checking the status of the server (for debugging etc) or serve as sample implementations of a functionality which would be absorbed in a GUI base system. Any package in 2 may be worthwhile to be shipped separately. But why bother at all about 3? Libs: The libs can be split up in three cathegories: 1. low level C-bindings for the protocol: libXv, libXcursor, ... 2. Xlib and friends. 3. Toolkits. libXt, libXaw ... I would say 1. needs to be shipped within xc/ as it reflects the version of the extensions shipped with the server. Some people are talking about shipping 2. separately. This could be done, of course, still, I don't see a huge benefit. And why bother about 3 at all? These toolkits are mostly used by legacy applications, they are not under heavy development. The Servers: Building then separately is difficult. To many common parts. The drivers could be built separately but we have an SDK for that. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Can I hide the cursor?
Matthew Allum writes: *but* if you use a libXcursor theme with every cursor icon fully transparent you can *really* get rid of the cursor, an app changing the cursors appearance just changes it to another 'invisible' cursor. I've not seen this 'technique' discussed before. You can do so for the core cursor also by creating new cursor font with blank glyphs. However if the application specifies it's own cursor you're lost. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Xtrans: -nolisten with aliases
attached patch is an alternative solution for the nolisten handling
of aliases.
It takes the aliases from a list explicitely thus allowing a finer
control than by checking for the equality of the interface specific
functions.
Any opinions?
Egbert.
Index: Xtrans.c
===
RCS file: /home/eich/XFree86/devel/xc/lib/xtrans/Xtrans.c,v
retrieving revision 3.32
diff -u -r3.32 Xtrans.c
--- Xtrans.c24 Jul 2003 13:50:18 - 3.32
+++ Xtrans.c7 Aug 2003 14:35:40 -
@@ -26,7 +26,7 @@
from The Open Group.
*/
-/* $XFree86: xc/lib/xtrans/Xtrans.c,v 3.31 2003/07/20 16:12:15 tsi Exp $ */
+/* $XFree86: xc/lib/xtrans/Xtrans.c,v 3.32 2003/07/24 13:50:18 eich Exp $ */
/* Copyright 1993, 1994 NCR Corporation - Dayton, Ohio, USA
*
@@ -779,6 +779,7 @@
{
Xtransport *trans;
+ int i = 0, ret = 0;
if ((trans = TRANS(SelectTransport)(protocol)) == NULL)
{
@@ -787,9 +788,16 @@
return -1;
}
-
+ if (trans-flags TRANS_ALIAS) {
+ if (trans-nolisten)
+ while (trans-nolisten[i]) {
+ ret |= TRANS(NoListen)(trans-nolisten[i]);
+ i++;
+ }
+ }
+
trans-flags |= TRANS_NOLISTEN;
- return 0;
+ return ret;
}
int
Index: Xtransint.h
===
RCS file: /home/eich/XFree86/devel/xc/lib/xtrans/Xtransint.h,v
retrieving revision 3.37
diff -u -r3.37 Xtransint.h
--- Xtransint.h 4 Aug 2003 10:32:21 - 3.37
+++ Xtransint.h 7 Aug 2003 14:45:50 -
@@ -26,7 +26,7 @@
from The Open Group.
*/
-/* $XFree86: xc/lib/xtrans/Xtransint.h,v 3.36 2003/07/24 13:50:19 eich Exp $ */
+/* $XFree86: xc/lib/xtrans/Xtransint.h,v 3.37 2003/08/04 10:32:21 eich Exp $ */
/* Copyright 1993, 1994 NCR Corporation - Dayton, Ohio, USA
*
@@ -226,7 +226,7 @@
#endif /* TRANS_CLIENT */
#ifdef TRANS_SERVER
-
+char **nolisten;
XtransConnInfo (*OpenCOTSServer)(
struct _Xtransport *, /* transport */
char *, /* protocol */
Index: Xtranslcl.c
===
RCS file: /home/eich/XFree86/devel/xc/lib/xtrans/Xtranslcl.c,v
retrieving revision 3.39
diff -u -r3.39 Xtranslcl.c
--- Xtranslcl.c 26 Nov 2002 01:12:30 - 3.39
+++ Xtranslcl.c 7 Aug 2003 15:07:03 -
@@ -2495,6 +2495,21 @@
* call to SelectTransport() in Xtrans.c.
*/
+#ifdef TRANS_SERVER
+static char * local_aliases[] = {
+# ifndef sun
+ pts,
+# endif
+ named,
+# ifndef sun
+# ifndef SCO325
+ isc,
+# endif
+ sco,
+# endif
+ NULL };
+#endif
+
Xtransport TRANS(LocalFuncs) = {
/* Local Interface */
local,
@@ -2503,6 +2518,7 @@
TRANS(LocalOpenCOTSClient),
#endif /* TRANS_CLIENT */
#ifdef TRANS_SERVER
+ local_aliases,
TRANS(LocalOpenCOTSServer),
#endif /* TRANS_SERVER */
#ifdef TRANS_CLIENT
@@ -2544,6 +2560,7 @@
TRANS(LocalOpenCOTSClient),
#endif /* TRANS_CLIENT */
#ifdef TRANS_SERVER
+ NULL,
TRANS(LocalOpenCOTSServer),
#endif /* TRANS_SERVER */
#ifdef TRANS_CLIENT
@@ -2585,6 +2602,7 @@
TRANS(LocalOpenCOTSClient),
#endif /* TRANS_CLIENT */
#ifdef TRANS_SERVER
+ NULL,
TRANS(LocalOpenCOTSServer),
#endif /* TRANS_SERVER */
#ifdef TRANS_CLIENT
@@ -2626,6 +2644,7 @@
TRANS(LocalOpenCOTSClient),
#endif /* TRANS_CLIENT */
#ifdef TRANS_SERVER
+ NULL,
TRANS(LocalOpenCOTSServer),
#endif /* TRANS_SERVER */
#ifdef TRANS_CLIENT
@@ -2665,6 +2684,7 @@
TRANS(LocalOpenCOTSClient),
#endif /* TRANS_CLIENT */
#ifdef TRANS_SERVER
+ NULL,
TRANS(LocalOpenCOTSServer),
#endif /* TRANS_SERVER */
#ifdef TRANS_CLIENT
Index: Xtransos2.c
===
RCS file: /home/eich/XFree86/devel/xc/lib/xtrans/Xtransos2.c,v
retrieving revision 3.8
diff -u -r3.8 Xtransos2.c
--- Xtransos2.c 25 Mar 2003 03:38:32 - 3.8
+++ Xtransos2.c 7 Aug 2003 14:58:09 -
@@ -833,6 +833,7 @@
TRANS(Os2OpenCOTSClient),
#endif /* TRANS_CLIENT */
#ifdef TRANS_SERVER
+ NULL,
TRANS(Os2OpenCOTSServer),
#endif /* TRANS_SERVER */
#ifdef TRANS_CLIENT
Index: Xtranssock.c
===
RCS file: /home/eich/XFree86/devel/xc/lib/xtrans/Xtranssock.c,v
retrieving revision 3.60
diff -u -r3.60 Xtranssock.c
--- Xtranssock.c24 Jul 2003 13:50:19 - 3.60
+++ Xtranssock.c7 Aug 2003 14:50:46 -
@@ -27,7 +27,7 @@
from the copyright holders.
*/
-/* $XFree86: xc/lib/xtrans/Xtranssock.c,v 3.59 2003/07/18 15:39:48 tsi Exp $ */
+/* $XFree86: xc/lib/xtrans/Xtranssock.c,v 3.60 2003/07/24 13:50:19 eich Exp $ */
/* Copyright 1993, 1994 NCR Corporation - Dayton, Ohio,
Re: Fix for Xlib with ipv6 support on ipv4 only systems
Mark Vojkovich writes: On Fri, 8 Aug 2003, Egbert Eich wrote: Mark Vojkovich writes: Out of curiosity. Is the ipv6 supposed to be working properly now? Last time I updated, I noticed that remote operation was broken. That is, Xlib was unable to connect to a remote system (I assume it didn't work with internet sockets anymore, but unix domain sockets still worked). Hm, what did you do? I never had any issues connecting to a remote system. Neither thru ipv4 nor ipv6. The only thing I noticed was that there are still issues with authetication for ipv6. For mu tests I used the -ac option to get around this. Did you get any error messages? The server is on dhcp-178-150:0 and is slightly newer than XFree86 4.3, but is not from any recent CVS. It is pre-ipv6 support. It has access control disabled (xhost +). The client is on dhcp-178-251 and is using fairly recent libraries from CVS. The DISPLAY is set to dhcp-178-150:0.0 and I get: _X11TransSocketOpen: socket() failed for tcp _X11TransSocketOpenCOTSClient: Unable to open socket for tcp _X11TransOpen: transport open failed for tcp/dhcp-178-150:0 xterm Xt error: Can't open display: dhcp-178-150:0.0 I find that: 1) The 4.3 libraries can connect to a CVS server. 2) CVS libraries can connect to a CVS server. 3) CVS libraries cannot connect to a 4.3 server. It looks like the same problem Andrew had. Your Xlib is built with IPv6 support, but your kerneld doesn't support it. One of the patches I've posted is supposed to take care of it. I still have a huge backlog of email to read. If noone has objected so far I will commit my fixes later. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Can I hide the cursor?
Since this problem comes up quite frequently I have made an article at: http://xfree86.linuxwiki.org/AdvancedTopicsFAQ about how to do this. Egbert. Andrew C Aitchison writes: On Wed, 6 Aug 2003, [gb2312] tom wrote: I want to hide the cursor when I using touchscreen in XFree86 4.20, I found that this quesstion have been discussed three times,but no answer.Then,does this means I can't hide the cursor at all? Can xsetroot resolve this problem? I tried but faild.I just can't change the cursor with it. I think that X fundamentally requires that you have exactly one cursor. You can however change the way it looks by changing the cursor font. You can write a cursor font which has an invisible cursor, so the user will not see anything. (I don't remember the syntax, but there several ways of changing cursor font). The only problem I see with that is that any application can change the cursor font, and some applications use their own font, so you can't guarantee that a cursor will never appear. However this will only happen when such an application has focus, so should not be a major problem. -- Andrew C Aitchison ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SlowBCopy, IA64, PCI bus corruption
John Dennis writes: Now it seems to me that using extra machine instructions (asm version) or no-op IO is inherently a risky solution to this problem. It would appear there is some interval of time one must wait for individual VGA bus transactions complete. The number of extra machine instructions and/or no-op IO to insert seems to be purely a guess and highly dependent on the processor and the bus its sitting on. The fact this works on one class of machines and not another does not surprise me at all. No, I've tried this already. The out() on port 0x80 did some flushing appearantly which made things work. Note that I arrived at this solution purely by guessing. There may be a better fix for that. 3) Can we come up with a scheme that introduces a known timing delay (e.g. usleep) such that we don't have to make arbitrary guesses as to how much no-op is needed in the loop on a given system? I don't think so. See above. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SlowBCopy, IA64, PCI bus corruption
Mark Vojkovich writes:
NVIDIA root caused this at one point and came to the conclusion
that Linux kernel was incorrectly mapping the memory as cached.
Experiments with setting bit{63} of Base Register fixed the
problem.
OK, this sounds like a very reasonable explanation.
Egbert.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Fix for Xlib with ipv6 support on ipv4 only systems
The path below will fix the problem that arises when running
a client on an inet4 only system over tcp with Xlib compiled
with inet6 support.
If noone objects I'll commit it.
Egbert.
Index: Xtranssock.c
===
RCS file: /home/eich/cvs/xc/lib/xtrans/Xtranssock.c,v
retrieving revision 1.1.1.10
diff -u -r1.1.1.10 Xtranssock.c
--- Xtranssock.c6 Aug 2003 16:17:24 - 1.1.1.10
+++ Xtranssock.c7 Aug 2003 13:12:47 -
@@ -192,6 +192,7 @@
{tcp,AF_INET,SOCK_STREAM,SOCK_DGRAM,0},
#else /* IPv6 */
{tcp,AF_INET6,SOCK_STREAM,SOCK_DGRAM,0},
+{tcp,AF_INET,SOCK_STREAM,SOCK_DGRAM,0}, /* fallback */
{inet6,AF_INET6,SOCK_STREAM,SOCK_DGRAM,0},
#endif
#endif /* TCPCONN */
@@ -275,20 +276,20 @@
*/
static int
-TRANS(SocketSelectFamily) (char *family)
+TRANS(SocketSelectFamily) (int first, char *family)
{
int i;
PRMSG (3,SocketSelectFamily(%s)\n, family, 0, 0);
-for (i = 0; i NUMSOCKETFAMILIES;i++)
+for (i = first + 1; i NUMSOCKETFAMILIES;i++)
{
if (!strcmp (family, Sockettrans2devtab[i].transname))
return i;
}
-return -1;
+return (first == -1 ? -2 : -1);
}
@@ -418,7 +419,7 @@
#endif
#endif
) {
- PRMSG (1, SocketOpen: socket() failed for %s\n,
+ PRMSG (2, SocketOpen: socket() failed for %s\n,
Sockettrans2devtab[i].transname, 0, 0);
xfree ((char *) ciptr);
@@ -483,26 +484,25 @@
{
XtransConnInfo ciptr;
-inti;
+inti = -1;
PRMSG (2, SocketOpenCOTSClient(%s,%s,%s)\n,
protocol, host, port);
SocketInitOnce();
-if ((i = TRANS(SocketSelectFamily) (thistrans-TransName)) 0)
-{
- PRMSG (1,
- SocketOpenCOTSClient: Unable to determine socket type for %s\n,
- thistrans-TransName, 0, 0);
- return NULL;
-}
-
-if ((ciptr = TRANS(SocketOpen) (
- i, Sockettrans2devtab[i].devcotsname)) == NULL)
-{
- PRMSG (1,SocketOpenCOTSClient: Unable to open socket for %s\n,
- thistrans-TransName, 0, 0);
+while ((i = TRANS(SocketSelectFamily) (i, thistrans-TransName)) = 0) {
+ if ((ciptr = TRANS(SocketOpen) (
+i, Sockettrans2devtab[i].devcotsname)) != NULL)
+ break;
+}
+if (i 0) {
+ if (i == -1)
+ PRMSG (1,SocketOpenCOTSClient: Unable to open socket for %s\n,
+ thistrans-TransName, 0, 0);
+ else
+ PRMSG (1,SocketOpenCOTSClient: Unable to determine socket type for %s\n,
+ thistrans-TransName, 0, 0);
return NULL;
}
@@ -524,25 +524,24 @@
{
XtransConnInfo ciptr;
-inti;
+inti = -1;
PRMSG (2,SocketOpenCOTSServer(%s,%s,%s)\n, protocol, host, port);
SocketInitOnce();
-if ((i = TRANS(SocketSelectFamily) (thistrans-TransName)) 0)
-{
- PRMSG (1,
- SocketOpenCOTSServer: Unable to determine socket type for %s\n,
- thistrans-TransName, 0, 0);
- return NULL;
-}
-
-if ((ciptr = TRANS(SocketOpen) (
- i, Sockettrans2devtab[i].devcotsname)) == NULL)
-{
- PRMSG (1,SocketOpenCOTSServer: Unable to open socket for %s\n,
- thistrans-TransName, 0, 0);
+while ((i = TRANS(SocketSelectFamily) (i, thistrans-TransName)) = 0) {
+ if ((ciptr = TRANS(SocketOpen) (
+i, Sockettrans2devtab[i].devcotsname)) != NULL)
+ break;
+}
+if (i 0) {
+ if (i == -1)
+ PRMSG (1,SocketOpenCOTSServer: Unable to open socket for %s\n,
+ thistrans-TransName, 0, 0);
+ else
+ PRMSG (1,SocketOpenCOTSServer: Unable to determine socket type for %s\n,
+ thistrans-TransName, 0, 0);
return NULL;
}
@@ -592,25 +591,24 @@
{
XtransConnInfo ciptr;
-inti;
+inti = -1;
PRMSG (2,SocketOpenCLTSClient(%s,%s,%s)\n, protocol, host, port);
SocketInitOnce();
-if ((i = TRANS(SocketSelectFamily) (thistrans-TransName)) 0)
-{
- PRMSG (1,
- SocketOpenCLTSClient: Unable to determine socket type for %s\n,
- thistrans-TransName, 0, 0);
- return NULL;
-}
-
-if ((ciptr = TRANS(SocketOpen) (
- i, Sockettrans2devtab[i].devcotsname)) == NULL)
-{
- PRMSG (1,SocketOpenCLTSClient: Unable to open socket for %s\n,
- thistrans-TransName, 0, 0);
+while ((i = TRANS(SocketSelectFamily) (i, thistrans-TransName)) = 0) {
+ if ((ciptr = TRANS(SocketOpen) (
+i, Sockettrans2devtab[i].devcotsname)) != NULL)
+ break;
+}
+if (i 0) {
+ if (i == -1)
+ PRMSG (1,SocketOpenCLTSClient: Unable to open socket for %s\n,
+ thistrans-TransName, 0, 0);
+ else
+ PRMSG
Re: TRANS_OPEN_MAX in Xtransint.h
Marc Aurele La France writes: You should be able to test for _SC_OPEN_MAX instead of __GNU__. Oops, yep, that should work, too, of course, thanks - stupid me. Presently I check for _POSIX_VERSION = 199309 as POSIX.1 conformant systems require sysconf(). Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: rough code paths draft doc
Mathieu Lacage writes: hi, I eventually got over my previous AddInputHandler puzzling and kept on reading code until I finished the included rough outline of useful code paths in the XServer. I've extended the article about AddInputHandler() have you read it? I am planning to turn this into a real documentation but real life matters make it unreasonable for me to finish this before the end of august. As such, I thought some people might find it useful as-is. If you want you can use the Wiki to publish your documentation. It has a development section. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
COMPOUND_TEXT handling of iso8859-15
Bugzilla #228 claims that the handling of iso8859-15 in COMPOUND_TEXT is incorrect. According to the ctext documentation no extended segments should be used for any approved standard encoding. According to the newer revision of this doc (xc/doc/specs/CTEXT/ctext.tbl.ms) is8859-15 is such an approved standard encoding. However XFree86 contains code to grant backward compatibility to XFree86 3.x that uses extended encodings for this. How importand is the backward compatibility to versions of Xlib for 3.x? Should we remove this code which makes our COMPOUND_TEXT handling violate the specs? Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xf86AddInputHandler
Mathieu Lacage writes: hi, I have spent some time recently to dive into XFree86 source code: I am looking into learning more how it works to understand better X performance in my application. One of the things I don't really get is what xf86AddInputHandler is supposed to be used for. Despite reading a lot of code and grepping multiple times, I found only very few locations using xf86AddInputHandler and I could not figure out what it is used for. I'd be most grateful for any kind of hint :) Please take a look at: http://xfree86.linuxwiki.org/xf86_2a_2a_20Functions Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
Daniel Stone writes: Yes, but what's the alternate solution? I really don't like the changed-case solution, as that sets a precedent of sorts. A note should be made somewhere of the moved files. One could name it hewlett-packard if lowercase is importand. KDE moves files around all the time. It's all you can do to work around the limitations of a fundamentally crippled system. Yes, but we don't. Due to the reason given above. The uppercase/lowercase issue doesn't justify breaking builds of checkouts of older versions. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
TRANS_OPEN_MAX in Xtransint.h
There is the following report in bugzilla (#97): - On Redhat 8 at any rate, the TRANS_OPEN_MAX constant should be compiled to a call to sysconf(), but is actually compiled into a default of 256. This breaks my app, which for various reasons opens 256 file descriptors. As the kernel default limit is 1024, the fact that Xlib has this value compiled in means the app will randomly abort when 256 is reached. There is a test case for this that I will attach. -- Anyway, sysconf() is only used if __GNU__ is defined. However the appropriate sysconf() call seems to be standard POSIX.1, therefore we should use some other macro indicating that it should be used instead of a fixed value. Any idea? Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
Matthieu Herrb writes: I wrote (in a message from Sunday 27) Keith Packard wrote (in a message from Wednesday 23) While supporting multiple -nolisten arguments is good, I suggest that the current '-nolisten tcp' should include both inet4 and inet6 tcp options; most people use '-nolisten tcp' to avoid exposing an open port to the X server to the network. -nolisten inet4 don't listen for TCP/IPv4 connections -nolisten inet6 don't listen for TCP/IPv6 connections -nolisten tcp don't listen for any TCP connections I agree here, except that it looks like Sun and X.Org are using inet for IPv4, not inet4. I'm going to do this change. Here's a proposed patch. When a -nolisten argument is an alias, it will look for transport entries matching this alias (ie using the same methods) and set the NOLISTEN flag there. I plan to commit this in a few days, unless someone finds out that this is wrong. The patch looks good, but it bases alias on the use of identical funtions. That means an alias will allways disable all protocols that share functions. I don't know if this is always desirable. For instance we could not have the aliases tcp4 and tcp6 to alias inet and inet6. My idea was therefore to put the aliases and the functions they map to into a separate table. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: twm crash with debug info
Not too many people seem to use xsm together with twm these days.
All relevant changes that in this area took place at or before
Apr,8th 1997. This code came from the SI.
Well, try the patch below.
Whoever added session management support to twm (and forgot to
document it in the man page) should check this.
Egbert.
Index: add_window.c
===
RCS file: /home/eich/cvs/xc/programs/twm/add_window.c,v
retrieving revision 1.1.1.7
diff -u -r1.1.1.7 add_window.c
--- add_window.c12 Dec 2002 14:43:38 - 1.1.1.7
+++ add_window.c28 Jul 2003 17:07:56 -
@@ -209,6 +209,13 @@
FetchWmProtocols (tmp_win);
FetchWmColormapWindows (tmp_win);
+if (name == NULL)
+ tmp_win-name = strdup(NoName);
+else {
+ tmp_win-name = strdup(name);
+ free(name);
+}
+
if (GetWindowConfig (tmp_win,
saved_x, saved_y, saved_width, saved_height,
restore_iconified, restore_icon_info_present,
@@ -277,12 +284,6 @@
tmp_win-transient = Transient(tmp_win-w, tmp_win-transientfor);
tmp_win-nameChanged = 0;
-if (name == NULL)
- tmp_win-name = strdup(NoName);
-else {
- tmp_win-name = strdup(name);
- free(name);
-}
if (tmp_win-class.res_name == NULL)
tmp_win-class.res_name = NoName;
if (tmp_win-class.res_class == NULL)
Re: patch procedure ..
Sven Goethel writes: sorry for being lazy and not RTFM, but after i send a patch to the patch email addy, and i have received an acknowledge .. - how long does it takes to get an answer - usually - will it happen to get no answer at all ? Hm, how long ago did send the email? I was under the impression that these lists don't exist any more as the bugzilla is the preferred way to submit patches: http://www.xfree86.org/developer.html Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
Marc Aurele La France writes: On Wed, 23 Jul 2003, Egbert Eich wrote: Marc Aurele La France writes: I don't like the peppering of this code with more OS #ifdef's. I think the approach espoused by Itojun, Todd, Matthieu and Andrew is better. So maybe you can tell what the big difference is? So maybe not. I've already stated I cannot test IPv6 function. As such, I'm here more as an overseer, and in that capacity I am of the opinion that this code need not be unnecessarily OS-#ifdef'ed. Take that as you see fit. OK, I've taken out the 'defined (linux)' stuff as I agree with you that it is ugly. I expect the code would work on all other platforms, although I cannot test it. The reason why I left the 'defined (linux)' in there was that platforms that don't have the broken Linux behavior suffer a minor penalty: server 1 started with: X -nolisten inet6 -nolisten unix -nolock :0 server 2 started with: X -nolisten unix :0 -nolock The second server doesn't catch that the first one is already using port 6000 for ipv4 as bind to the ipv4 port fails silently if bind to the ipv6 port was successful. This may be a rare condition, though. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
This 'nolisten' code was added on 1996/11/24 with revision 3.22.
The cvs log only says:
revision 3.22
date: 1996/11/24 09:58:50; author: dawes; state: Exp; lines: +14 -1
updates
I would assume it was taken straight from a SI merge.
Alan Coopersmith writes:
Maybe I'm missing something, but I always thought the XFree86 nolisten
code was overly complicated, and this just seems to make it worse. When
we added -nolisten to Xsun, we got multiple listeners for free with a
simpler implementation, contained entirely in utils.c:
else if ( strcmp( argv[i], -nolisten) == 0)
{
if(++i argc) {
if (_XSERVTransNoListen(argv[i])) {
FatalError (Failed to disable listen for %s transport,
argv[i]);
}
} else
UseMsg();
}
I have made a patch similar to Matthieu's but this looks much simpler
:-}
Does anybody know why we use this complicated approach?
Egbert.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
Hmm, with the current approach a -nolisten to an alias has no effect anyway. A '-nolisten tcp' will have the same effect as a '-nolisten unix': None. The reason is that a flag is set for the protocol however when the protocols are initialized the aliases aren't checked. Also tcp is aliased to IPv6. I don't know why this was done but I would expect that it violates the principle of least surprise: When connecting with 'display tcp/1.2.3.4:0' a IPv6 socket is created and the IPv4 connection is done over the IPv6 socket. This may not work on systems without IPv6 support. Egbert. Keith Packard writes: Around 23 o'clock on Jul 23, Matthieu Herrb wrote: Here's a patch to allow multiple '-nolisten' options on the command line. To disable both IPv4 and IPv6 transports, one needs to say: X -nolisten tcp -nolisten inet6 While supporting multiple -nolisten arguments is good, I suggest that the current '-nolisten tcp' should include both inet4 and inet6 tcp options; most people use '-nolisten tcp' to avoid exposing an open port to the X server to the network. -nolisten inet4 don't listen for TCP/IPv4 connections -nolisten inet6 don't listen for TCP/IPv6 connections -nolisten tcp don't listen for any TCP connections -keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
Andrew C Aitchison writes: Egbert's latest patch compiles and runs, but it isn't addressing my problem. This is with Red Hat 8.0 Linux 2.4.20-19.8 gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) (I have the same problem with Red Hat 6.2). The system is *not* configured with IPv6, and socket(PF_INET6, SOCK_STREAM, 0) fails with -1 EAFNOSUPPORT (Address family not supported by protocol). This is not unexpected, but how are we supposed to carry on and try PF_INET ? Thus xbiff -display inet/localhost:10 works (I'm connecting over ssh), but xbiff -display localhost:10 fails reporting _X11TransSocketOpen: socket() failed for tcp _X11TransSocketOpenCOTSClient: Unable to open socket for tcp _X11TransOpen: transport open failed for tcp/localhost:10 Error: Can't open display: localhost:10 That's what I've explained in my previous message. Can we just declare that inet and inet6 both match tcp ? The way the code is currently written aliases like tcp alias to exactly one transport type. There is no fallback mechanism. The easiest way would be to alias tcp to inet instead of inet6. Or somebody designes a fallback mechansim. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
Matthias Scheler writes: On Tue, Jul 22, 2003 at 09:14:08PM +0200, Egbert Eich wrote: As I tried to explain binding to an IPv6 socket implicitely binds to an IPv4 socket. That's a bug. According to what I've heared it is intended and therefore considered a feature. I'm not going to argue about this, I just observed this behavior. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
Fabio Massimo Di Nitto writes:
On Tue, 22 Jul 2003, Matthias Scheler wrote:
On Tue, Jul 22, 2003 at 08:03:35PM +0200, Egbert Eich wrote:
The current CVS code produces the error:
_XSERVTransSocketINETCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
Fatal server error:
Cannot establish any listening sockets - Make sure an X server isn't already
running
bind() returns an EADDRINUSE error when binding to the second IP
protocol (in CVS it is IPv6).
When I switch the order of initialization around and skip the IPv4
protocol if IPv6 initialization was successful, everything works:
I can connect thru IPv6 and IPv4.
This sounds like a bug in Linux's socket implementation.
Not really. Linux has been always working like this. the USAGI patch for
linux kernel implements a runtime configurable option to separate ipv6 and
ipv4 bindings.
Something like:
int off = 0;
[...]
if (setsockopt(listen_socket, IPPROTO_IPV6, IPV6_V6ONLY, off,
sizeof (off)) 0) {
?
This of course would help, however it wouldn't address the problem on
the existing systems.
Egbert.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
Matthias Scheler writes: I wasn't suggesting to use it on Linux. My suggestion was to revert to using a single socket on all platforms and use the above code to enable accepting IPv4 connections on *BSD. Yes, I understand. I was just looking for a decend way of making things work on Linux. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
I've made the patch below which takes care of the problem for me.
I have tried several different versions, I didn't really like any
of them.
This code is one of the rare pieces of code that is rather well
structured and relatively free of any ugly hacks. This fix makes
it a lot uglier, what I particularly don't like is that it now
depends on the order in which the listeners for the different
protocols are created.
I've tried several different solutions including the use if
getaddrinfo(), everything made this code more ugly.
Any better solutions are welcome. If there are none, I'll commit this
code.
Egbert.
Index: Xtrans.c
===
RCS file: /home/x-cvs/xc/lib/xtrans/Xtrans.c,v
retrieving revision 3.31
diff -u -w -r3.31 Xtrans.c
--- Xtrans.c20 Jul 2003 16:12:15 - 3.31
+++ Xtrans.c23 Jul 2003 13:35:40 -
@@ -90,10 +90,10 @@
#endif /* STREAMSCONN */
#if defined(TCPCONN)
{ TRANS(SocketTCPFuncs), TRANS_SOCKET_TCP_INDEX },
-{ TRANS(SocketINETFuncs), TRANS_SOCKET_INET_INDEX },
#if defined(IPv6) defined(AF_INET6)
{ TRANS(SocketINET6Funcs),TRANS_SOCKET_INET6_INDEX },
#endif /* IPv6 */
+{ TRANS(SocketINETFuncs), TRANS_SOCKET_INET_INDEX },
#endif /* TCPCONN */
#if defined(DNETCONN)
{ TRANS(DNETFuncs), TRANS_DNET_INDEX },
@@ -768,10 +768,10 @@
#ifdef TRANS_SERVER
int
-TRANS(CreateListener) (XtransConnInfo ciptr, char *port)
+TRANS(CreateListener) (XtransConnInfo ciptr, char *port, unsigned int flags)
{
-return ciptr-transptr-CreateListener (ciptr, port);
+return ciptr-transptr-CreateListener (ciptr, port, flags);
}
int
@@ -1037,6 +1037,9 @@
char buffer[256]; /* ??? What size ?? */
XtransConnInfo ciptr, temp_ciptrs[NUMTRANS];
intstatus, i, j;
+#if defined (linux) defined(IPv6) defined(AF_INET6)
+Bool ipv6_succ = FALSE;
+#endif
PRMSG (2,MakeAllCOTSServerListeners(%s,%p)\n,
port ? port : NULL, ciptrs_ret, 0);
@@ -1046,6 +1049,7 @@
for (i = 0; i NUMTRANS; i++)
{
Xtransport *trans = Xtransports[i].transport;
+ unsigned int flags = 0;
if (trans-flagsTRANS_ALIAS || trans-flagsTRANS_NOLISTEN)
continue;
@@ -1065,8 +1069,13 @@
trans-TransName, 0, 0);
continue;
}
+#if defined (linux) defined(IPv6) defined(AF_INET6)
+ if ((Xtransports[i].transport_id == TRANS_SOCKET_INET_INDEX
+ ipv6_succ))
+ flags |= ADDR_IN_USE_ALLOWED;
+#endif
- if ((status = TRANS(CreateListener (ciptr, port))) 0)
+ if ((status = TRANS(CreateListener (ciptr, port, flags))) 0)
{
if (status == TRANS_ADDR_IN_USE)
{
@@ -1098,6 +1107,11 @@
}
}
+#if defined (linux) defined(IPv6) defined(AF_INET6)
+ if (Xtransports[i].transport_id == TRANS_SOCKET_INET6_INDEX)
+ ipv6_succ = TRUE;
+#endif
+
PRMSG (5,
MakeAllCOTSServerListeners: opened listener for %s, %d\n,
trans-TransName, ciptr-fd, 0);
@@ -1165,7 +1179,7 @@
continue;
}
- if ((status = TRANS(CreateListener (ciptr, port))) 0)
+ if ((status = TRANS(CreateListener (ciptr, port, 0))) 0)
{
if (status == TRANS_ADDR_IN_USE)
{
Index: Xtrans.h
===
RCS file: /home/x-cvs/xc/lib/xtrans/Xtrans.h,v
retrieving revision 3.21
diff -u -w -r3.21 Xtrans.h
--- Xtrans.h20 Jul 2003 16:12:15 - 3.21
+++ Xtrans.h23 Jul 2003 13:35:41 -
@@ -339,7 +339,8 @@
int TRANS(CreateListener)(
XtransConnInfo,/* ciptr */
-char * /* port */
+char *,/* port */
+unsigned int /* flags */
);
int TRANS(NoListen) (
Index: Xtransint.h
===
RCS file: /home/x-cvs/xc/lib/xtrans/Xtransint.h,v
retrieving revision 3.35
diff -u -w -r3.35 Xtransint.h
--- Xtransint.h 26 Nov 2002 01:12:30 - 3.35
+++ Xtransint.h 23 Jul 2003 13:35:41 -
@@ -26,7 +26,7 @@
from The Open Group.
*/
-/* $XFree86: xc/lib/xtrans/Xtransint.h,v 3.35 2002/11/26 01:12:30 dawes Exp $ */
+/* $XFree86: xc/lib/xtrans/Xtransint.h,v 3.34 2002/11/20 23:00:36 dawes Exp $ */
/* Copyright 1993, 1994 NCR Corporation - Dayton, Ohio, USA
*
@@ -283,10 +283,13 @@
);
#ifdef TRANS_SERVER
+/* Flags */
+# define ADDR_IN_USE_ALLOWED 1
int(*CreateListener)(
XtransConnInfo, /* connection */
- char * /* port */
+ char *, /* port */
+ unsigned int/* flags */
);
int(*ResetListener)(
Index: Xtranssock.c
===
RCS file:
Re: IPv6 problems on Linux
Fabio Massimo Di Nitto writes: I didn't check/produce any code but the easiest way to implement in linux is something like (if the user does not specify --nolisten): bind to ipv6 if it works ok otherwise fail silently bind to ipv4 if it works ok otherwise fail with error message. specifing --nolisten the fail conditions might change their behaviour. This is basically what i did when i first tried the ipv6 kame patch for X. The Xserverallows one or more protocols to fail unless the -nopn option is given. You are pretty much suggesting to make this option the default with allowing ipv6 to fail silently. That's possible. I'd like to hear more opinions on that. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
Oops, I haven't rebuilt the server. Maybe this should be changed to int, 0 and 1. Egbert. Dr Andrew C Aitchison writes: On Wed, 23 Jul 2003, Egbert Eich wrote: I've made the patch below which takes care of the problem for me. make[3]: Entering directory `/home/XFree86/4.2/std/xc/lib/ICE' rm -f transport.o gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I../.. -I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -I../../lib/xtrans -DUNIXCONN -DTCPCONN -DHAS_STICKY_DIR_BIT -DHAS_FCHOWN -DIPv6 -DICE_t -DTRANS_CLIENT -DTRANS_SERVER-fPIC transport.c In file included from transport.c:85: ../../lib/xtrans/Xtrans.c: In function `_IceTransMakeAllCOTSServerListeners': ../../lib/xtrans/Xtrans.c:1041: `Bool' undeclared (first use in this function) ../../lib/xtrans/Xtrans.c:1041: (Each undeclared identifier is reported only once ../../lib/xtrans/Xtrans.c:1041: for each function it appears in.) ../../lib/xtrans/Xtrans.c:1041: parse error before ipv6_succ ../../lib/xtrans/Xtrans.c:1074: `ipv6_succ' undeclared (first use in this function) ../../lib/xtrans/Xtrans.c:1112: `TRUE' undeclared (first use in this function) make[3]: *** [transport.o] Error 1 Should that be BOOL, TRUE (and FALSE) as defined I don't know where (or Bool, True and False as defiend in ICElib.h) ? -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED]http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
Marc Aurele La France writes:
I don't like the peppering of this code with more OS #ifdef's. I think
the approach espoused by Itojun, Todd, Matthieu and Andrew is better.
So maybe you can tell what the big difference is?
It tries to preserve more of the old behavoir with
respect to the -nolisten and -pn/-nopn option.
You can of course remove the 'defined (Linux)' as this
patch should work for all systems as it allows
bind() for ipv4 to fail silently.
I've attached a corrected version below.
Egbert.
Index: Xtrans.c
===
RCS file: /home/x-cvs/xc/lib/xtrans/Xtrans.c,v
retrieving revision 3.31
diff -u -w -r3.31 Xtrans.c
--- Xtrans.c20 Jul 2003 16:12:15 - 3.31
+++ Xtrans.c23 Jul 2003 13:35:40 -
@@ -90,10 +90,10 @@
#endif /* STREAMSCONN */
#if defined(TCPCONN)
{ TRANS(SocketTCPFuncs), TRANS_SOCKET_TCP_INDEX },
-{ TRANS(SocketINETFuncs), TRANS_SOCKET_INET_INDEX },
#if defined(IPv6) defined(AF_INET6)
{ TRANS(SocketINET6Funcs),TRANS_SOCKET_INET6_INDEX },
#endif /* IPv6 */
+{ TRANS(SocketINETFuncs), TRANS_SOCKET_INET_INDEX },
#endif /* TCPCONN */
#if defined(DNETCONN)
{ TRANS(DNETFuncs), TRANS_DNET_INDEX },
@@ -768,10 +768,10 @@
#ifdef TRANS_SERVER
int
-TRANS(CreateListener) (XtransConnInfo ciptr, char *port)
+TRANS(CreateListener) (XtransConnInfo ciptr, char *port, unsigned int flags)
{
-return ciptr-transptr-CreateListener (ciptr, port);
+return ciptr-transptr-CreateListener (ciptr, port, flags);
}
int
@@ -1037,6 +1037,9 @@
char buffer[256]; /* ??? What size ?? */
XtransConnInfo ciptr, temp_ciptrs[NUMTRANS];
intstatus, i, j;
+#if defined (linux) defined(IPv6) defined(AF_INET6)
+Bool ipv6_succ = FALSE;
+#endif
PRMSG (2,MakeAllCOTSServerListeners(%s,%p)\n,
port ? port : NULL, ciptrs_ret, 0);
@@ -1046,6 +1049,7 @@
for (i = 0; i NUMTRANS; i++)
{
Xtransport *trans = Xtransports[i].transport;
+ unsigned int flags = 0;
if (trans-flagsTRANS_ALIAS || trans-flagsTRANS_NOLISTEN)
continue;
@@ -1065,8 +1069,13 @@
trans-TransName, 0, 0);
continue;
}
+#if defined (linux) defined(IPv6) defined(AF_INET6)
+ if ((Xtransports[i].transport_id == TRANS_SOCKET_INET_INDEX
+ ipv6_succ))
+ flags |= ADDR_IN_USE_ALLOWED;
+#endif
- if ((status = TRANS(CreateListener (ciptr, port))) 0)
+ if ((status = TRANS(CreateListener (ciptr, port, flags))) 0)
{
if (status == TRANS_ADDR_IN_USE)
{
@@ -1098,6 +1107,11 @@
}
}
+#if defined (linux) defined(IPv6) defined(AF_INET6)
+ if (Xtransports[i].transport_id == TRANS_SOCKET_INET6_INDEX)
+ ipv6_succ = TRUE;
+#endif
+
PRMSG (5,
MakeAllCOTSServerListeners: opened listener for %s, %d\n,
trans-TransName, ciptr-fd, 0);
@@ -1165,7 +1179,7 @@
continue;
}
- if ((status = TRANS(CreateListener (ciptr, port))) 0)
+ if ((status = TRANS(CreateListener (ciptr, port, 0))) 0)
{
if (status == TRANS_ADDR_IN_USE)
{
Index: Xtrans.h
===
RCS file: /home/x-cvs/xc/lib/xtrans/Xtrans.h,v
retrieving revision 3.21
diff -u -w -r3.21 Xtrans.h
--- Xtrans.h20 Jul 2003 16:12:15 - 3.21
+++ Xtrans.h23 Jul 2003 13:35:41 -
@@ -339,7 +339,8 @@
int TRANS(CreateListener)(
XtransConnInfo,/* ciptr */
-char * /* port */
+char *,/* port */
+unsigned int /* flags */
);
int TRANS(NoListen) (
Index: Xtransint.h
===
RCS file: /home/x-cvs/xc/lib/xtrans/Xtransint.h,v
retrieving revision 3.35
diff -u -w -r3.35 Xtransint.h
--- Xtransint.h 26 Nov 2002 01:12:30 - 3.35
+++ Xtransint.h 23 Jul 2003 13:35:41 -
@@ -26,7 +26,7 @@
from The Open Group.
*/
-/* $XFree86: xc/lib/xtrans/Xtransint.h,v 3.35 2002/11/26 01:12:30 dawes Exp $ */
+/* $XFree86: xc/lib/xtrans/Xtransint.h,v 3.34 2002/11/20 23:00:36 dawes Exp $ */
/* Copyright 1993, 1994 NCR Corporation - Dayton, Ohio, USA
*
@@ -283,10 +283,13 @@
);
#ifdef TRANS_SERVER
+/* Flags */
+# define ADDR_IN_USE_ALLOWED 1
int(*CreateListener)(
XtransConnInfo, /* connection */
- char * /* port */
+ char *, /* port */
+ unsigned int/* flags */
);
int(*ResetListener)(
Index: Xtranssock.c
===
RCS file: /home/x-cvs/xc/lib/xtrans/Xtranssock.c,v
retrieving revision 3.59
diff -u -w -r3.59 Xtranssock.c
--- Xtranssock.c18 Jul 2003
Re: IPv6 problems on Linux
I've accidently sent the wrong file before. Sorry.
Egbert.
Index: Xtrans.c
===
RCS file: /home/x-cvs/xc/lib/xtrans/Xtrans.c,v
retrieving revision 3.31
diff -u -r3.31 Xtrans.c
--- Xtrans.c20 Jul 2003 16:12:15 - 3.31
+++ Xtrans.c23 Jul 2003 18:17:17 -
@@ -90,10 +90,10 @@
#endif /* STREAMSCONN */
#if defined(TCPCONN)
{ TRANS(SocketTCPFuncs), TRANS_SOCKET_TCP_INDEX },
-{ TRANS(SocketINETFuncs), TRANS_SOCKET_INET_INDEX },
#if defined(IPv6) defined(AF_INET6)
{ TRANS(SocketINET6Funcs),TRANS_SOCKET_INET6_INDEX },
#endif /* IPv6 */
+{ TRANS(SocketINETFuncs), TRANS_SOCKET_INET_INDEX },
#endif /* TCPCONN */
#if defined(DNETCONN)
{ TRANS(DNETFuncs), TRANS_DNET_INDEX },
@@ -768,10 +768,10 @@
#ifdef TRANS_SERVER
int
-TRANS(CreateListener) (XtransConnInfo ciptr, char *port)
+TRANS(CreateListener) (XtransConnInfo ciptr, char *port, unsigned int flags)
{
-return ciptr-transptr-CreateListener (ciptr, port);
+return ciptr-transptr-CreateListener (ciptr, port, flags);
}
int
@@ -1037,6 +1037,9 @@
char buffer[256]; /* ??? What size ?? */
XtransConnInfo ciptr, temp_ciptrs[NUMTRANS];
intstatus, i, j;
+#if defined(IPv6) defined(AF_INET6)
+intipv6_succ = 0;
+#endif
PRMSG (2,MakeAllCOTSServerListeners(%s,%p)\n,
port ? port : NULL, ciptrs_ret, 0);
@@ -1046,6 +1049,7 @@
for (i = 0; i NUMTRANS; i++)
{
Xtransport *trans = Xtransports[i].transport;
+ unsigned int flags = 0;
if (trans-flagsTRANS_ALIAS || trans-flagsTRANS_NOLISTEN)
continue;
@@ -1065,8 +1069,13 @@
trans-TransName, 0, 0);
continue;
}
+#if defined(IPv6) defined(AF_INET6)
+ if ((Xtransports[i].transport_id == TRANS_SOCKET_INET_INDEX
+ ipv6_succ))
+ flags |= ADDR_IN_USE_ALLOWED;
+#endif
- if ((status = TRANS(CreateListener (ciptr, port))) 0)
+ if ((status = TRANS(CreateListener (ciptr, port, flags))) 0)
{
if (status == TRANS_ADDR_IN_USE)
{
@@ -1098,6 +1107,11 @@
}
}
+#if defined(IPv6) defined(AF_INET6)
+ if (Xtransports[i].transport_id == TRANS_SOCKET_INET6_INDEX)
+ ipv6_succ = 1;
+#endif
+
PRMSG (5,
MakeAllCOTSServerListeners: opened listener for %s, %d\n,
trans-TransName, ciptr-fd, 0);
@@ -1165,7 +1179,7 @@
continue;
}
- if ((status = TRANS(CreateListener (ciptr, port))) 0)
+ if ((status = TRANS(CreateListener (ciptr, port, 0))) 0)
{
if (status == TRANS_ADDR_IN_USE)
{
Index: Xtrans.h
===
RCS file: /home/x-cvs/xc/lib/xtrans/Xtrans.h,v
retrieving revision 3.21
diff -u -r3.21 Xtrans.h
--- Xtrans.h20 Jul 2003 16:12:15 - 3.21
+++ Xtrans.h23 Jul 2003 18:17:18 -
@@ -339,7 +339,8 @@
int TRANS(CreateListener)(
XtransConnInfo,/* ciptr */
-char * /* port */
+char *,/* port */
+unsigned int /* flags */
);
int TRANS(NoListen) (
Index: Xtransint.h
===
RCS file: /home/x-cvs/xc/lib/xtrans/Xtransint.h,v
retrieving revision 3.35
diff -u -r3.35 Xtransint.h
--- Xtransint.h 26 Nov 2002 01:12:30 - 3.35
+++ Xtransint.h 23 Jul 2003 18:17:18 -
@@ -26,7 +26,7 @@
from The Open Group.
*/
-/* $XFree86: xc/lib/xtrans/Xtransint.h,v 3.35 2002/11/26 01:12:30 dawes Exp $ */
+/* $XFree86: xc/lib/xtrans/Xtransint.h,v 3.34 2002/11/20 23:00:36 dawes Exp $ */
/* Copyright 1993, 1994 NCR Corporation - Dayton, Ohio, USA
*
@@ -283,10 +283,13 @@
);
#ifdef TRANS_SERVER
+/* Flags */
+# define ADDR_IN_USE_ALLOWED 1
int(*CreateListener)(
XtransConnInfo, /* connection */
- char * /* port */
+ char *, /* port */
+ unsigned int/* flags */
);
int(*ResetListener)(
Index: Xtranssock.c
===
RCS file: /home/x-cvs/xc/lib/xtrans/Xtranssock.c,v
retrieving revision 3.59
diff -u -r3.59 Xtranssock.c
--- Xtranssock.c18 Jul 2003 15:39:48 - 3.59
+++ Xtranssock.c23 Jul 2003 18:17:18 -
@@ -783,7 +783,8 @@
static int
TRANS(SocketCreateListener) (XtransConnInfo ciptr,
-struct sockaddr *sockname, int socknamelen)
+struct sockaddr *sockname,
+int socknamelen, unsigned int flags)
{
intnamelen = socknamelen;
@@ -803,7 +804,10 @@
while (bind (fd, (struct sockaddr *) sockname, namelen) 0)
{
- if (errno ==
IPv6 problems on Linux
When creating an IPv6 socket on Linux an IPv4 socket seems to be created also. The current CVS code produces the error: _XSERVTransSocketINETCreateListener: ...SocketCreateListener() failed _XSERVTransMakeAllCOTSServerListeners: server already running Fatal server error: Cannot establish any listening sockets - Make sure an X server isn't already running bind() returns an EADDRINUSE error when binding to the second IP protocol (in CVS it is IPv6). When I switch the order of initialization around and skip the IPv4 protocol if IPv6 initialization was successful, everything works: I can connect thru IPv6 and IPv4. I'm surprised that noone else sees this problem. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
Matthias Scheler writes: This sounds like a bug in Linux's socket implementation. It should allow an IPv4 and an IPv6 socket to bind to the same port number. This is a common programming pratice for *BSD or Solaris. As I tried to explain binding to an IPv6 socket implicitely binds to an IPv4 socket. That's why binding an IPv4 socket and then an IPv6 socket to the same port fails. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Driver for 69030
Yes, I'm sure the posting refers to a ChipsTechnologies 69030. This is already supported in 4.3, including video playback. Capture isn't supported as I never had anything to test it with. I would have replied to the original email if I had been able to understand it better. Egbert. Tim Roberts writes: On Tue, 22 Jul 2003 10:27:44 +0530, Nitin Mahajan wrote: Hello Everyone! Iam writing a driver for 69030 card. I have to support CIF and QCIF formats. WHICH 69030? Surely you must realize that chip numbers are not unique industry-wide. If you are talking about the Asiliant 69030, are you aware that a Linux driver already exists? It is a renamed version of the old Chips Technologies 65550, which was supported in XFree86 3.x. http://www.humboldt.co.uk/matc.html 1. The format says that a frame rate of 30fps is required for both. 2.Each frame should have a. 144 lines and 176 pixels/line for QCIF. b. 288 lines and 352 pixels/line for CIF. Now my interpretation is that the second point above refers to the frame size and the driver implementation (video modes)has nothing to do with it. Is this interpretation of mine is correct? I doubt it, but I'm confused by your mixing of graphics and video. When you say a frame rate of 30fps is required, what are you talking about? Do you mean video coming in through the zoom video port? Or are you talking about ordinary software-decoded movies? Tells us WHAT you have to support at 30fps, and perhaps we can offer suggestions. Second question is that, how do I achive the frame rate of 30fps? 30fps for what? I have programmed the BitBLT engine for the card,but that also puts only 64Kb data on screen in on shot,so always I need to divide the Image into 64KB parts. Are you talking about system-memory-to-video-memory transfers? I'm surprised to hear there is a 64K limitation in any relatively modern graphics card. Are you sure about that? -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
Matthias Scheler writes:
It is necessary in at least NetBSD and OpenBSD because the kernel won't
let you accept IPv4 connection on an IPv6 socket by default. As FreeBSD's
IPv6 is AFAK also KAME based I would expect that it shows the same behaviour.
... while simply binding to IPv6 and letting it handle both was the
way we coded it to work, and had it working on both Solaris and Linux.
You can use that scheme in *BSD, too, if you use setsockopt() like this:
int off = 0;
[...]
if (setsockopt(listen_socket, IPPROTO_IPV6, IPV6_V6ONLY, off,
sizeof (off)) 0) {
/* error handling */
[...]
}
[...]
I was looking for the IPV6_V6ONLY on Linux, but these options don't
seem to exist there.
Egbert.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Solution for 855GM video memory issue
This could easily be integrated in the driver (it would be much more easy to do than writing a separate program) but like you say in your disclaimer: we cannot guarantee that nothing bad happens. Therefore I don't think it is the way to go. However what I find more interesting is that you updated the BIOS with one form the Intel web site. Intel claims that this issue has been fixed with later versions of the BIOS, so that the driver can use a specific BIOS function to teach the BIOS of the changed size. Therefore - according to Intel - you should not need this program any more. Egbert. Christian Zietz writes: Hi, PLEASE CC any answers to [EMAIL PROTECTED] as I'm not subscribed to the list. first, my problem as summarized by David H. Dawes: It appears that some 855GM-based laptops only pre-allocate 1MB of video memory, and don't provide any BIOS configuration options for increasing this. Although the XFree86 driver will allocate more (if the correct agpgart kernel support is present), the mechanism used to inform the video BIOS of the additional allocation doesn't seem to be implemented on these laptops. This results in the video BIOS refusing to program video modes that require more than 1MB (actually 832KB). As far as I know there hasn't been any solution for this. So I spent my day digging through Intel datasheets and disassembling the Video BIOS and came up with a hack that works for me: The Video BIOS stores the memory size it thinks it is allocated at a certain location in RAM. This location is write-protected by default but can me made writable by setting the appropiate chipset registers. That's what I do and then I can set the memory size so XFree86 works with higher resolutions and color depths. Since I don't have the XFree86 sources to patch, I implemented this hack in a separate program called 855patch. It takes the desired video memory size in KB as argument. Note that it only tells the BIOS what memory size to expect but does NOT actually allocate the memory. So you'll have to set the VideoRAM option in the XF86Config Device section to at least the size you used when calling 855patch (more is fine) or your system will probably crash. The hack works nicely on my Dell Inspiron 500m laptop (Intel Video BIOS version 2945) and the mechanism I described is also implemented in version 2973 I downloaded from Intel.com. So I suggest you try it, if you have the problem described above. I'd be very glad if this snippet - if it works on other systems - found it's way to XFree86 sources. Disclaimer: Obviously I can't guarantee that it'll work for you. So don't blame me if something bad happens. Download: http://www.chzsoft.com.ar/855patch.c Christian Zietz, now able to run XFree86 in 1024x768x16bpp ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
-fexeptions in library build rules with callbacks
We have a bug report at http://bugs.xfree86.org/show_bug.cgi?id=503 that suggests that when building libraries with callbacks using gcc the option -fexeptions should be used. It enables C++ programs to catch the exceptions. I've talked to a gcc expert and he says that using this option is sane. It adds unwind information and on some targets it supresses a few optimizations that break unwinding, however these optimizations are no big deal. In statically linked binaries the exception tables should automatically be removed if the binary does not use them. Any opinions? Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Savage Driver Replacement?
Alan Messer writes: Tim Roberts wrote: I've recently been made aware of the XFree86 Savage driver that VIA released and is now available on Alan Hourihane's web site. This driver is so much superior to the one I've been maintaining that I should be embarrassed. My question is: has anyone actually taken an action item to incorporate this into the 4.3.99 tree? I'd like to reiterate Tim's question. Have Via recently released drivers been integrated into 4.3.99? I had the feeling that the drivers in 4.3.99 were based on Via's previous release? Yes, there is a VIA driver in CVS. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
