Re: Multihead ISA

2004-04-07 Thread Egbert Eich
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

Re: Vesa Driver Probe

2004-04-04 Thread Egbert Eich
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.

Re: Multihead ISA

2004-04-04 Thread Egbert Eich
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

Re: Vesa Driver Probe

2004-04-01 Thread Egbert Eich
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.

Re: Vesa Driver Probe

2004-04-01 Thread Egbert Eich
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

CVS Update: xc (branch: trunk)

2004-03-31 Thread Egbert Eich
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/03/31 13:17:21 Log message: - adding missing test for the i845 Modified files: xc/programs/Xserver/hw/xfree86/drivers/i810/: i830_driver.c Revision ChangesPath 1.54

Re: Vesa Driver Probe

2004-03-31 Thread Egbert Eich
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

CVS Update: xc (branch: trunk)

2004-03-30 Thread Egbert Eich
it for the client may result in segfault if the client has already freed it (Egbert Eich). 46. Protect removeOverlapsWithBrides() from NULL pointer in target (Egbert Eich). 45. Fixed stretching option and centering in CT driver (Egbert Eich). 44. Added support for memory size

Re: vesa probe is inadequate

2004-03-30 Thread Egbert Eich
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

Re: vesa probe is inadequate

2004-03-30 Thread Egbert Eich
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

Re: [XFree86] Compilation and Installation on x86-64 ...

2004-03-16 Thread Egbert Eich
Damien Touraine writes: Hello, I have an Athlon 64 computer. I was really happy to discover that XFree is dealing with such architecture. However, in my case I would like to have both 64 bits libraries as well as 32 bits ones (such as on SGI architecture where libraries are compiled

Re: __AMD64__ or __amd64__ ?

2004-02-29 Thread Egbert Eich
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

CVS Update: xc (branch: trunk)

2004-02-25 Thread Egbert Eich
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/02/25 04:53:15 Log message: - changed default setting of DisplayInfo to 'on' (printing a infos to the log file describing how to work around a possible hang) - fixed a minor typo in int10/linux.c

Re: i855GM: New BIOS breaks i810-driver

2004-02-25 Thread Egbert Eich
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

Re: i855GM: New BIOS breaks i810-driver

2004-02-23 Thread Egbert Eich
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

Re: i855GM: New BIOS breaks i810-driver

2004-02-19 Thread Egbert Eich
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

CVS Update: xc (branch: trunk)

2004-02-17 Thread Egbert Eich
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/02/17 07:30:26 Log message: 806. Fixing DPMS: let modification of DPMS timeout take effect immeditately, don't activate DPMS when disabled (Egbert Eich). Modified files: xc/programs/Xserver

CVS Update: xc (branch: trunk)

2004-02-05 Thread Egbert Eich
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 04/02/05 10:25:00 Log message: 788. Fixing segfaults that may happen in some corner cases on VT switch and int10 initialization (Egbert Eich). Modified files: xc/programs/Xserver/hw/xfree86

Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.

2004-01-30 Thread Egbert Eich
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

Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.

2004-01-30 Thread Egbert Eich
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

Re: building X11 in separate pieces

2004-01-11 Thread Egbert Eich
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

Re: [XFree86] kvm switch causing mouse problems

2004-01-08 Thread Egbert Eich
Mark Vojkovich writes: XFree86's mouse protocol handling doesn't seem to be able to handle interruptions/inconsistencies in the protocol stream that kvm switches cause. As far as I can tell, XFree86 has always had this problem. Other than switching VTs to force a the server to

Re: SPLIT_WC_REGIONS - anyone out there?

2003-11-07 Thread Egbert Eich
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

Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)

2003-10-31 Thread Egbert Eich
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.

RE: C+T 69030 driver on powerpc

2003-10-28 Thread Egbert Eich
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:

RE: C+T 69030 driver on powerpc

2003-10-28 Thread Egbert Eich
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

Re: [XFree86] Problem with xrandr

2003-10-24 Thread Egbert Eich
xrandr currently doesn't support rotation. You can use the old rotation sceme - however you have to disable xrandr. Egbert. [EMAIL PROTECTED] writes: Hello, i want to use my komputer as a projector with fresnels lens, but i'got problem with rotation a screen. Xrandr not working. xrandr

Re: C+T 69030 driver on powerpc

2003-10-23 Thread Egbert Eich
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

Re: [XFree86] Problem configuring NeoMagic NM2070 in DECpos2 PC

2003-10-23 Thread Egbert Eich
John Murray writes: I'm trying to get X working on a DECpos2 (point of sale PC device) running Slackware 9.1. Previously I got it working using Slackware 7.1 and its version of XFree86. On that one I had to configure it as a generic VGA device because I'd read that the NM2070 driver

Re: Cygwin/XFree86 Bugs?

2003-10-22 Thread Egbert Eich
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

Re: Cygwin/XFree86 Bugs?

2003-10-22 Thread Egbert Eich
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

Re: Cygwin/XFree86 Bugs?

2003-10-22 Thread Egbert Eich
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

Re: [XFree86] RESOLVED: I830WaitLpRing() lockup

2003-10-21 Thread Egbert Eich
Eric Anholt writes: I haven't been following this too closely, but was this happening only on BSDs? The VBE thing stuck out in my mind, as there was just an issue in DRI (the radeon mergedfb changes) where using the generic int10 emulation caused the driver to crash, while the

Re: [XFree86] xvidtune 845G

2003-10-21 Thread Egbert Eich
Bob Marcan writes: Does XFree86 4.3.xxx CVS support xvidtune on 845G ? Since the 845 driver supports only modes that can be set by the BIOS xvidtune does not work for chipsets 815. Egbert. Intel board D845GBV, latest BIOS Red Hat Linux release 9 (Shrike) XFree86-4.3.0-2 [encijan

Re: Re[2]: [XFree86] RESOLVED: I830WaitLpRing() lockup

2003-10-21 Thread Egbert Eich
Alexey E. Suslikov writes: Tuesday, October 21, 2003, 5:07:59 PM, you wrote: int 10 type generic emulator 4.3.0/OpenBSD 3.4 no genericbad cksm 4.3.0/Linux 2.4.23bad cksmbad cksm

Re: [XFree86] Cirrus 5446

2003-10-17 Thread Egbert Eich
Eduardo Huertas writes: Hi, I've been having problems configuring a Cirrus Logic 5446 even though your site says it is supported. Even if the site says it is supported it just means the driver knows about the chip in is in prinicple capable of driving this chip. The driver itself is

Re: [XFree86] All annoying error in I830WaitLpRing() in some details

2003-10-17 Thread Egbert Eich
David Dawes writes: Does further switching give you a working XFree86 display again? What happens if you exit that XFree86 session and restart XFree86? FWIW, when I was working in the driver, I wasn't able to reproduce any switching-related problems with the hardware I had and the

Re: [XFree86] Cirrus 5446

2003-10-14 Thread Egbert Eich
Eduardo Huertas writes: Hi, I've been having problems configuring a Cirrus Logic 5446 even though your site says it is supported. That's euphemism. It probably should be changed. The chipset is supported because the driver knows about it and should theoretically be able to drive it.

Re: SiliconMotion - unable to restore VGA screen on exit

2003-10-12 Thread Egbert Eich
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

Re: SiliconMotion - unable to restore VGA screen on exit

2003-10-11 Thread Egbert Eich
[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

Re: [XFree86] All annoying error in I830WaitLpRing() in some details

2003-10-09 Thread Egbert Eich
Nicolas Joly writes: * NoAccel... ok * Accel ... KO * Accel + SWcursor + 4Mo ... KO * Accel + NeedRingBufferLow ... KO For the NoAccel case, i successfully switched about 20 times to the 4 text consoles and went back to X without

CVS Update: xc (branch: trunk)

2003-10-08 Thread Egbert Eich
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/08 04:13:03 Log message: 483. Added support for Siliconmotion Cougar3DR chip (Bugzilla #754, Chris Edgington). 482. Cygwin: * Added another German keyboard layout. * Added

CVS Update: xc (branch: xf-4_3-branch)

2003-10-08 Thread Egbert Eich
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/10/08 10:56:35 Log message: 1008. Fixed definititon of UseInstalledOnCrossCompile so that it never is undefined (Harlod L. Hunt II). 1007. Fixing crash on ia64 because of wrong setjmp buffer

Re: [XFree86] Belkin KVM switch and Gnome, console mouse service

2003-10-07 Thread Egbert Eich
jmw writes: thanks for the reply. i don't know, but suspect this MS PS/2 Intellimouse is mostly passive -- no 'replug'. if there were such a command, i expect it would be part of a driver that is in Win 2K (or other Windows O/S). and that could explain why i don't see this problem

Re: [XFree86] All annoying error in I830WaitLpRing() in some details

2003-10-07 Thread Egbert Eich
Alexey E. Suslikov writes: bang! this is it: the bug still exist, at least on i830m (like in my case). setting NoAccel true is turning off Xaa functions for first. linux people did so. i did too, but with no success :( I've tried very hard and I'm not seeing the problem any more. If

CVS Update: xc (branch: trunk)

2003-10-02 Thread Egbert Eich
. . Added YUY2 video format. . Corrected accel framebuffer pitches and max screen height (BugzillaR #528, Egbert Eich). 474. Moved DisableMMIO() out of the unmap() function, added call to EnableMMIO() to EnterVT() to work around lockup problems when switching between

Re: [XFree86] Belkin KVM switch and Gnome, console mouse service

2003-09-28 Thread Egbert Eich
Mark Vojkovich writes: On Fri, 26 Sep 2003, jmw wrote: Switching VTs and back should help. XFree86's mouse protocol parsing just doesn't seem to be smart enough to deal with this sort of thing. I'm not sure if this is the problem of the mouse protocol parsing. The mouse needs to

Re: Exporting sched_yield to the drivers

2003-09-25 Thread Egbert Eich
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.

Re: Exporting sched_yield to the drivers

2003-09-23 Thread Egbert Eich
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

Re: Exporting sched_yield to the drivers

2003-09-23 Thread Egbert Eich
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

Re: C version of ucs2any.pl

2003-09-21 Thread Egbert Eich
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

Re: Wrong order of a timeouts processing in WaitForSomething.

2003-09-21 Thread Egbert Eich
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

Re: [XFree86] Intermittent error with Radeon

2003-09-21 Thread Egbert Eich
a carbonnel writes: Hi, sorry for my bad English, I want to speack about : (EE) end of block range 0x3b begin 0xfffc Please send us an output of 'scanpci -v' Thanks, Egbert. ___ XFree86 mailing list [EMAIL PROTECTED]

Re: [XFree86] Xfree having problems finding out how much onboard memory

2003-09-21 Thread Egbert Eich
Sycholic writes: Basically Im getting a error in the /var/log file telling me due to a hardware bug? here is the error Im getting. If anything can I define it by hand or would this be futile since X probally wont know the memory addresses. Its a 16meg Millenium II card. (WW) MGA(0):

Re: developer XFree86

2003-09-15 Thread Egbert Eich
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

Re: [XFree86] Lacking organization

2003-09-15 Thread Egbert Eich
Dan Mergens writes: Egbert, There is enough information out there if you're an experience google search and have a day to search through all the bad information and unanswered questions. What is really needed is clear organization and links to the helpful sites such as the one you

Re: Fwd: 69030 driver

2003-09-12 Thread Egbert Eich
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

Re: [XFree86] Lacking organization

2003-09-12 Thread Egbert Eich
Mark Vojkovich writes: There was a group working on a FAQ, but I'm not sure what the status on that is. We could sure use some efforts to keep the level of redundant questions down. We get too many i845G doesn't work, too many fixed font questions, etc... The XFree86 merely

Re: XInput: The device type in XListInputDevices comes up again...

2003-09-10 Thread Egbert Eich
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

Re: [XFree86] Support / This List

2003-09-10 Thread Egbert Eich
Brian A. Seklecki writes: This is simply an observation with absolutely no insinuation intended. I don't don't want a flame war or a lecture about the support aspects of free software. I'm well aware: I'd simply like to start a discussion on how to help improve this situation.

Re: i855 and 1400x1050

2003-09-09 Thread Egbert Eich
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

CVS Update: xc (branch: trunk)

2003-09-08 Thread Egbert Eich
that may arise (Bugzilla # 659, Alan Coopersmith). 432. Backing out 321.: sysMem gets initialized once during server lifetime (Egbert Eich). 431. Fixing X11.tmpl to set XFTINCLUDES after defining a non-standard path to fontconfig, adding FONTCONFIGINCLUDES to the build

Re: XInput: The device type in XListInputDevices comes up again...

2003-09-08 Thread Egbert Eich
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

Re: i855 and 1400x1050

2003-09-08 Thread Egbert Eich
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

Re: i855 and 1400x1050

2003-09-08 Thread Egbert Eich
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

Re: [I18n] Bug #631

2003-09-08 Thread Egbert Eich
Theppitak Karoonboonyanan writes: Just a little puzzled about the status of Bug #631 [Adding Angkhankhu to Thai (TIS-820.2538) keymap]. It's marked as FIXED, but no change appeared in my CVS update this morning. Do I miss something? No, you were just a little early. I've committed

Re: XInput: The device type in XListInputDevices comes up again...

2003-09-05 Thread Egbert Eich
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

Re: XInput: The device type in XListInputDevices comes up again...

2003-09-05 Thread Egbert Eich
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,

Re: [Fonts] After-XTT's extension of the encoding field.

2003-09-05 Thread Egbert Eich
Juliusz Chroboczek writes: EE Saying 'core fonts need to go way' is equivalent to saying EE 'lets change the core protocol'. That's out of the question. I don't think the protocol spec requires the existence of any fonts beyond fixed and cursor. Right, but this doesn't solve the

Re: XInput: The device type in XListInputDevices comes up again...

2003-09-03 Thread Egbert Eich
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

Re: XInput: The device type in XListInputDevices comes up again...

2003-09-02 Thread Egbert Eich
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

Re: XInput: The device type in XListInputDevices comes up again...

2003-09-02 Thread Egbert Eich
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

Re: XInput: The device type in XListInputDevices comes up again...

2003-09-01 Thread Egbert Eich
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

Re: XInput: The device type in XListInputDevices comes up again...

2003-09-01 Thread Egbert Eich
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

Re: XInput: The device type in XListInputDevices comes up again...

2003-09-01 Thread Egbert Eich
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

Re: XInput: The device type in XListInputDevices comes up again...

2003-09-01 Thread Egbert Eich
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.

Re: XInput: The device type in XListInputDevices comes up again...

2003-08-31 Thread Egbert Eich
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

Re: XInput: The device type in XListInputDevices comes up again...

2003-08-31 Thread Egbert Eich
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.

Re: XInput: The device type in XListInputDevices comes up again...

2003-08-31 Thread Egbert Eich
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

Re: New device handling in X (was: XInput: The device type inXListInputDevices comes up again...)

2003-08-31 Thread Egbert Eich
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

Re: XInput: The device type in XListInputDevices comes up again...

2003-08-28 Thread Egbert Eich
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

Re: XInput: The device type in XListInputDevices comes up again...

2003-08-28 Thread Egbert Eich
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

Re: [XFree86] extract (gnu-tar) segfaults on debian SID

2003-08-28 Thread Egbert Eich
David Dawes writes: I can build a glibc22-based dynamically linked version (don't have any glibc23 systems here at the moment) and put that up for both the glibc22 and glibc23 bindists if that would help. I think it does. The the newer glibcs should be backward compatible. Egbert.

Re: *** xf86BiosREAD, IA64, Multi-card Init ***

2003-08-27 Thread Egbert Eich
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

Re: *** xf86BiosREAD, IA64, Multi-card Init ***

2003-08-27 Thread Egbert Eich
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

Re: XInput: The device type in XListInputDevices comes up again...

2003-08-27 Thread Egbert Eich
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

CVS Update: xc (branch: trunk)

2003-08-26 Thread Egbert Eich
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/26 04:34:57 Log message: 406. Added big5hkscs encoding to font encoding files (Bugzilla #575, Jungshik Shin). Modified files: xc/fonts/encodings/large/: Imakefile

CVS Update: xc (branch: xf-4_3-branch)

2003-08-26 Thread Egbert Eich
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/26 04:47:26 Log message: 1000. Fixed a crash when _XIMProtoOpenIM(), hich is called through XOpenIM() API when protocol IM is being set up, fails (Bugzilla #618, Hisashi MIYASHITA).

Re: cvs:drivers/via/via_driver.c: problem with Virtual

2003-08-26 Thread Egbert Eich
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

Re: *** xf86BiosREAD, IA64, Multi-card Init ***

2003-08-26 Thread Egbert Eich
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

Re: XInput: The device type in XListInputDevices comes up again...

2003-08-26 Thread Egbert Eich
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

CVS Update: xc (branch: trunk)

2003-08-25 Thread Egbert Eich
(Bugzilla #613, Alexey Baj, Egbert Eich). 401. Via driver: Fixed remaining globals, some formatting issues, out of memory handling in Xv overlay code and a couple of small glitches caused by the fixes (Bugzilla# 525, Alan Cox) Fixed some missing globals and static build

CVS Update: xc (branch: trunk)

2003-08-25 Thread Egbert Eich
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/25 11:55:31 Log message: 404. Passing correct virtual screen size to xf86ValidateModes() in VIA driver (Luc Verhaegen). Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG

CVS Update: xc (branch: trunk)

2003-08-25 Thread Egbert Eich
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/25 11:56:44 Log message: - added missing file Added files: xc/programs/Xserver/hw/xfree86/drivers/via/: via_capture.h ___ Cvs-commit mailing

Re: cvs:drivers/via/via_driver.c: problem with Virtual

2003-08-25 Thread Egbert Eich
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

Re: Static server build problems in via driver

2003-08-25 Thread Egbert Eich
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

CVS Update: xc (branch: trunk)

2003-08-22 Thread Egbert Eich
). 391. Fixed a possible source of Sig11 in Jamstudio driver (BugzillaR #617, Jonathan Hough, Egbert Eich). 390. Fixed building without RENDER support (BugzillaR #306, Mattieu Herrb, Egbert Eich). 389. Pass pointer obtained by Xalloc() to Xfree() not the one that may

Re: DPI with multiple heads and virtual desktops

2003-08-22 Thread Egbert Eich
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

Re: vfb port to xf86 device driver interface

2003-08-22 Thread Egbert Eich
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

Re: vfb port to xf86 device driver interface

2003-08-22 Thread Egbert Eich
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 :-)

  1   2   3   4   5   >