Re: XFree86 4.5.0 RC1 (4.4.99.901)
David, People have been telling me that the <[EMAIL PROTECTED]> address is bouncing. Could you please either fix the alias, or change the fonts.sgml document to use <[EMAIL PROTECTED]> ? (Or both.) Thanks, Juliusz ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: device driver - Kernel X XFree86 - USB - distribution
> So, are you saying that if I develop a Input Core driver (Serial and > USB) it is not necessary to develop a XFree86 driver? It's a little bit more exciting than that ;-) The good news is that if you develop a Linux input driver, any userspace application that groks /dev/event will be able to use your device. Additionally, if it's a relative device, any application that can grok the PS/2 mouse protocol will be able to use your device. The bad news is that as far as I know XFree86 does not yet have an input driver for /dev/event. Yes, this is a shame (I gladly take my part of the blame). However, - I've hacked together a simple /dev/event driver for KDrive (TinyX), which is available on http://www.pps.jussieu.fr/~jch/software/files/lxevent.c It works for both relative and absolute devices, converting the latter to relative in the driver (it was developed for a synaptics touchpad, but should work with any device that has three buttons). You're welcome to do anything you wish with this code (you don't need to credit me, except for keeping my copyright notice in the sources). - If you develop for the event interface, you will not need to design a new interface. Implementing a well-defined API will doubtless be simpler than rolling your own. - If you develop for the event interface, anyone with an absolute PS/2 or USB device will be able to help you with the XFree86 driver; if you use your private protocol, you'll be pretty much on your own. Good luck, Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: device driver - Kernel X XFree86 - USB - distribution
> I'm in chager of developing a driver for a pointing device (absolute > coordinates). > This device has two interfaces, Serial and USB. > I kwow it is possible to do XFree86 drivers for Serial and I've seen such source > code at XFree86 project. > 1- Is it possible to do the same thing for the USB interface? or Do > I have to write a linux kernel driver? If you're planning to develop for Linux only, is there any reason your device driver couldn't be written to interface with the generic Linux input framework? Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Documentation on Xfbdev
S> Where can I find some documentation of Xfbdev? man Xfbdev http://www.xfree86.org/current/Xfbdev.1.html http://www.pps.jussieu.fr/~jch/software/kdrive.html Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DGA - the future?
CH> we are missing a point here. you do know Xfree is used on handheld CH> devices like pda's etc. ? i have measured a full 20% speedup in CH> rendering with direct fb access compared to going via a CH> shmputimage pipeline on my ipaq, Good point. The same will be true of older machines (a 68K mac makes a great X terminal). Have you measured memcpy speed on those machines, so we can know whether it's actually the extra copy that bites you, or whether we're doing something wrong? Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DGA - the future?
JW>I'm just concerned that the DGA extension will be removed with JW> no adequete replacement. The main issue with DGA seems to be the JW> way it requires root privs and can write to other parts of JW> memory. Can we not have some sort of "/dev/dga" device or is this JW> not the place to ask ;) is this not feasible? James, I'm rather sympathetic to what you're trying to achieve (and I do know other legitimate applications for DGA), but unfortunately it can't be done. What Mark is speaking about is the added complexity to drivers to allow direct access to the framebuffer and synchronise with the client. Doing that through a device won't simplify matters. If you're working with small updates, you should be going through a shared mem pixmap and using ShmPutImage. Yes, this will cost you one extra copy (from your app to the shmem segment, and then from the shmem to the framebuffer), but that should not be noticable on modern hardware (which can typically push half a gig per second). If you do things right, you should be able to render directly to the shared mem segment, which will avoid the first copy. As an additional data point, I'd like to refer you to the shadowfb code, which basically introduces an additional buffer in the server and pushes all screen updated through that, basically what you'll be doing with a shmem segment. Experience shows that the shadowfb code is sufficiently fast in all cases, and actually faster than any form of direct unaccelerated rendering (except for filling areas). Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: __AMD64__ or __amd64__ ?
MH> If you do not know what __arch64__ is, then by all means read ISO MH> C99 and/or the gcc or other documentation. There is no mention of __arch64__ in the 18 January 1999 committee draft of C99, in the gcc-3.2 manual or in the CPP-3.2 manual. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: __AMD64__ or __amd64__ ?
MH> If the test is just to determine wether or not a 64bit MH> architecture is being built for, then __arch64__ is a better MH> test. What is a 64 bit architecture? Is it about address bus size? (The MC68020 is a 34-bit architecture?) About data bus size? About register size? (The MC68040 is an 80-bit architecture?) About the size that instructions operate on? (The P6 is a 128-bit architecture?) LP64 has a well-defined technical meaning (it's about the size of data types exported by the C compiler.) I have no idea what ``64-bit architecture'' may mean. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: event interface in Xfree86
JL> Is there any plans on writing drivers using the [Linux] event JL> interface It's most definitely a good idea. The event interface allows access to additionnal touchpad buttons, and it carries timestamped events. In order to use the timestamps, you'd need a unified mouse/keyboard driver that enqueues events from different sources in the right order. I've got a pretty hackish event-based driver for KDrive. It's pretty incomplete -- it doesn't implement the idea above yet --, and it's rather hackish, but you may find it useful as a starting point. http://www.pps.jussieu.fr/~jch/software/files/lxevent.c JL> I'm on the verge on writing some myself, but I've never written any JL> drivers before so... Go for it, by all means! Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.4.0 RC3
DD> Even FreeType requires something in the documentation I know that. I disagree with FreeType's licensing as much as I disagree with the new XFree86 license, and I have told David Turner what I think about it. David, the fact that other people use silly licensing terms does not mean that we should do. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.4.0 RC3
>> It was okay for Debian or FreeBSD to grab a routine that I wrote, >> as it was for Apple or Microsoft. DD> They still can use your code, because *you* choose the licence for DD> your code. And you choose one for yours, and Mark for his? The situation is going to become mighty confused. Are you trying to reduce the unemployment rate among lawyers? DD> Equivalence of attribution, as I've stated many times. Could you please explain what you mean? XFree86 contains code contributed by the CSG. You can use that code without crediting the CSG outside of the source. XFree86 contains code contributed by SGI. You can use that code without crediting SGI outside of the source. XFree86 contains code contributed by the XFree86 project. You cannot use that code, however, unless you credit XFree86 in a user-visible manner. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.4.0 RC3
DD> [XFree86] was not, as a whole, FSF-free before the change, let DD> alone GPL-compatible. Same after the change. But then XFree86 DD> has never factored in those two licensing criteria. That's not quite the point, David. Of the many reasons for which I was happy to contribute my work to XFree86 was that the old licence guaranteed that anyone could use my code. It was okay for Debian or FreeBSD to grab a routine that I wrote, as it was for Apple or Microsoft. Unless I've missed a post, you still haven't explained what it is that you're trying to achieve with the new licence. I would like to hear you justify that the advantages of the new licence justify what I perceive as a net loss in code availability. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Announcement: Modification to the base XFree86(TM) license.
David, Just to let you know that I disagree with this decision. The original license is clear and simple. It makes it simple for people to use our code without having to consult any lawyers. The new license might be confusing, and it contains an unpleasant ``advertising clause'' that might make it complicated to use our code. How was the license change decided? Where did the discussion (if any) happen? Who was consulted? Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: embed the fixed font in the X server binary
DD> Of course once this is done, the problem reports will change to "My X DD> apps can't find the fonts they need," or "Why is everything is using DD> the same ugly font?" ;-) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: embed the fixed font in the X server binary
TV> To the point: wouldn't it be benecifial to embed the fixed font in the X TV> server binary itself? Definitely (and the cursor font too). The TinyX (KDrive) server already does that. Unfortunately, it is not possible to use the KDrive built-in fonts code in the XFree86 server, as it pulls in quite a lot of stuff which shouldn't be in the core server (including the fontdir code, the PCF parser and libz). I've been planning to do a clean implementation of built-in fonts for quite some time, but as usual Real Work is keeping me distracted. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with X.Org [was: with images]
MK> i don't follow this line of argument. that kaleb guy said x.org was MK> going to MK> freedesktop and you think that's the solution? no que comprende. I understand it can be a little bit confusing if you don't have the background. All that follows is my private perception, and doesn't represent an official XFree86 opinion. Kaleb is a respected X11 wizard. While I do not know who is or used to be his employer, for as long as I can remember he has appeared to be close the the ``official'' guardians of the X11 standard -- used to be The Open Group, is X.Org right now. (I don't know whether this was already the case in the MIT X Consortium days.) Our relations with TOG were more or less non-existent, especially after the X11R6.4 licensing debacle; Kaleb was, I believe, the one person close to TOG we would sometimes have a chat with. When TOG gave up the X11 stewardship and X.Org was created, we were hoping to establish a more healthy relationship with them. This hope was abandoned when we actually tried to get them to standardise something we had done -- we were ignored for a year, and then flamed to death for distributing the very extension that had been ignored. (You will find the flamewar archives if you google for ``UTF8_STRING precipitously''.) Kaleb, I hope I didn't mis-represent anything. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with X.Org
>> If you can explain what we did wrong with UTF8_STRING, please do. KK> They did what they could, i.e. they added UTF8_STRING to the KK> registry. Oh wow. KK> As I indicated to you previously on xfree86-forum, you should be KK> hearing something before very long Oh good. So they aren't irrelevant at all. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with X.Org [was: with images]
KK> It'll take more than advocacy to make it a standard. I don't need to KK> tell you, I'm certain, that in Open Source software the best way to KK> make things happen is to do them. KK> To be a Standard though, you need to write a specification and have it KK> go through X.org's standardization process. A proof of concept, in the KK> form of an implementation, is useful too. Kaleb, If you can explain what we did wrong with UTF8_STRING, please do. Pro memoria, we have a sample implementation, we have a draft standard, and we spent over a year trying to get X.Org to notice. If, however, you cannot point out what we did wrong, then we can only conclude that freedesktop.org is a better forum for the standardi- sation of X protocol extensions. Regards, Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: (Warning long!) Re: X11 CVS with linux 2.6.0-test9?
FH> I suppose I could have a hardware problem, since my PC is a couple years FH> old now. However, I can leave the same computer just running a 2.4.x FH> kernel for days with no problems. HZ is 1000 by default in 2.6; the different scheduling might perhaps cause a deadlock somewhere. Can you try with a 2.6 kernel compiled with HZ being 100 and see whether you can reproduce the problem? Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: devices Xfbdev
>> server is now 866KB, which is still a wee bit over what I'd expect.] DD> I got about that for an IA32 build. So am I. Something happened, I used to get almost 100KB less than that. Unfortunately, I won't have time to track it down anytime soon. Anyone have time to try out Keith's tree on http://pdx.freedesktop.org/ ? Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: devices Xfbdev
[size problem solved over private e-mail; it was due to using X-TT, which links against all of its ``encoding converters''; Jessi's X server is now 866KB, which is still a wee bit over what I'd expect.] JB> can anyone plz tell me what devices does Xfbdev(and Xipaq) JB> expect in the /dev/ directory, to work properly? >From memory, it should need /dev/fb0, /dev/mem, and one of /dev/mouse, /dev/psaux or some other pointing device (see hw/kdrive/linux/mouse.c for the complete list of devices probed). I think its simplest to try out experimentally: strace -e open Xfbdev Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: More details about a kernel module (by GPfault)
RJ> An IOCTL shouldn't have any more overhead than reading or writing to a RJ> file... Make this a hundred cycles (and you're probably flushing some caches somewhere). That's 0.1 us on a 1GHz CPU. The machine I'm typing this on can do 2 milllion short thin lines per second. That's 0.5 us per line. If you do one ioctl per short line, you're paying 20% overhead for the ioctl. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Kernel Module? On second thought...
TR> You really need some way to identify the XFree86 server as TR> "trusted". In Linux today, the only mechanism for doing that is TR> suid root. I'm sorry to repeat what I've already said, but it isn't. It could very well be setgid xfree86, setgid hwaccess. Old SunOS had setgid kmem for ps and friends. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Kernel Module? On second thought...
RJ> Judging from the large number of *flames* I got for suggesting it, These weren't flames. They were fairly kind explanations. A flame is something completely different -- you'll see if you hang around some more ;-) Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: You suggest an upgrade, eh?
CR> Benchmarking is a bit like academic tests. It proves that you're good CR> at the benchmark, not at the task. You can't cheat at a benchmark. (To be a little bit less cryptical: benchmarks are all we've got to make sure we're making sense in our design and implementation. In the right hands, benchmarks don't lie. But benchmarks are useful for the programmer, who knows what exactly he's measuring. They are not necessarily useful for the user. End of bracket.) Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: More details about a kernel module (by GPfault)
RJ> Just add some IOCTL's for hardware acceleration). How much overhead does an ioctl involve ? (Rhethorical question.) Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: What about a kernel module?
AC> (Of course, we do this somewhat on Solaris/sparc, Do you document the interface ? Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: What about a kernel module?
>> I'd like to suggest that you implement device-specific code as a kernel >> module. Well, that won't happen; we already have working portable driver code in userspace, and there's no chance we'll port that to the Linux kernel. On the other hand, I do think that we'll end up using more kernel-side functionality than we currently do; perhaps someday we'll have enough of that to be able to run non-root servers, at least on hardware that does memory-mapped I/O (the iopl system call is for root only). TR> The key problem with this is that kernel modules are Linux-specific, and TR> further often need to be kernel-version specific. XFree86 runs quite well TR> in many non-Linux environments today. But that doesn't prevent it from using features specific to Linux when needed. Notice for example the use of the vm86old syscall in the Linux/i386 version of the int10 module, or the (optional) use of fbdev in quite a few drivers, or the future use of the /dev/input/event devices (hint, hint). Let alone the DRI. >> Implementing a kernel module might give access to more resources, like >> tighter console control, asynchronous accelerations, TR> No, I don't think any of that is true. DMA? Smarter polling of FIFO status? Retrace interrupt? The /dev/rtc driver is an example of a kernel module with the sole purpose of giving userspace access to an interrupt. TR> For security reasons, wouldn't you want to restrict access to the kernel TR> module to root programs anyway? You don't want arbitrary code accessing TR> your video card and changing the mode. There's normal Unix security for that; make a group xfree86, and put the users allowed to run the server in that group. Or make the server setgid xfree86, which is better than setuid root. Of course, I'm not arguing that it should be done, just pointing out that you're too fast dismissing the idea of having some tailor-made code on the Other Side. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xterminal 8-bit Colormap problems
MS> In de original programs we now get strange occurances of resizeable areas MS> that don't display there contents (text) after resizing or turn black after MS> resizing. The programs expect the backing-store window attribute to be honoured and XFree86 doesn't? (Anyone remember how to enable bs in XFree86?) Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Wrong order of a timeouts processing in WaitForSomething.
JG> So I'd just open the device and see if PS/2 mice work at this date. PS/2 mice and AT keyboards most definetily do work with the event interface, at least since 2.5.73 (the first 2.5 kernel I tested[1]). They do not work in current 2.4, where the event interface is for USB peripherals only. JG> So it is entirely possible everything is already there in current JG> Linux distributions. It's not in stock 2.4 yet. JG> So you still have to do a select/poll, read all pending input JG> events on all different devices, and merge the events in the JG> server into a single stream in time stamp order. Can that happen in dix, or should it be below? (Additionally, a large jump in time, say more than a second, should be treated as a barrier so as to deal with the clock being stepped. That would make one of the hacks in our hw layer go away.) Juliusz [1] It did work, but froze when compiling XFree86. 2.6.0-test4 works but the disk scheduler is disappointing, at least on my hardware. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Wrong order of a timeouts processing in WaitForSomething.
JG> In fact, the event interface exists in current 2.4; not JG> just 2.[45]. Look in /dev/input/event*. Some of us still use PS/2 mice... JG> Note that this interface is not just for mice, but is generalized JG> to be usable by pretty arbitrary input devices, Yes; it looks like all input devices go through the single event interface in 2.6. That would seem to guarantee correct ordering of events from different devices. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Wrong order of a timeouts processing in WaitForSomething.
Thanks for the explanation, Keith. KP> 2) Timestamp events accurately [...] KP> Better yet would be to have the kernel timestamp events with a KP> high-precision timer Linux 2.[56] does that on the new /dev/event interface (/dev/psaux would appear to be deprecated). Is it worth using? Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Wrong order of a timeouts processing in WaitForSomething.
KP> a) The original A/UX server had checkForInput marked from the SIGIO KP> handler and read device events in ProcessInputEvents. Why? Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: setjmp needs fixing again, here's the issues
JD> alignment requirement right how do we specify the alignment requirement
JD> to the compiler in a portable way such that it will build on a variety
JD> of systems and compilers?
typedef union {int i[1024]; long long l;} jmp_buf;
JD> Given the argument in 3 above I'd recommend taking out xf86jmp_buf and
JD> putting back in #include . It seems the simplist, most
JD> robust, and in practical terms sacrifices little.
I agree.
Juliusz
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: X for a cramped PC environment
HS> 1. anyone has been experimenting with X that's almost so tiny as HS> tinyX, and liked what they got? >> TinyX is full X11, so your question really doesn't make sense. HS> Well, it doesn't read a config file, Right, you meant XFree86 where you wrote X. HS> and the result is that I can't seem HS> to tell it to try several "obvious" places for a mouse, and use any of HS> them. Look at linux/mouse.c, around line 890. HS> I also can't whip up some sort of "trivial mouse setup" and tell HS> it which of a pile of mice drivers to try It will automatically try all supported mouse protocols. >> In XFree86 4.3, the TTF rasteriser also does Type 1 by default. In >> 4.4, it will also do BDF and PCF. HS> Urg. Thanks for the warning. I'm trying to chop a lot of size out HS> by getting rid of all but one rendering mode. Look at lib/font/FreeType/ftmodule.h and comment out any modules you don't need. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: X for a cramped PC environment
HS> So I'm wondering if: HS> 1. anyone has been experimenting with X that's almost so tiny as HS> tinyX, and liked what they got? TinyX is full X11, so your question really doesn't make sense. HS> 2. kdrive is an easier option instead of a patch kit in newer code HS> than 4.2.1? Eh? HS> 4. anyone knows a truetype/scalable cursor font? XFree86 includes a Type 1 version of the cursor font. You could use pfaedit to make a TTF version. In XFree86 4.3, the TTF rasteriser also does Type 1 by default. In 4.4, it will also do BDF and PCF. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 over Firewire !
RFC 872. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Pfaedit-devel] Re: [forum] Re: Choosing an extension for bitmap-only SFNTs
GW> Ok, I'm currently posting a new build of PfaEdit which will generate GW> embedded bitmap opentype fonts with extension ".otb" Considering the lack of serious objection to .otb, I consider it adopted. GW> (PfaEdit is currently generating 'OTTO', which is appropriate for GW> opentype fonts). I'm simply using the TrueType 1.0 signature. Windows refuses these fonts anyway. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Using S3's Savage drivers
Hi, I've been running S3's Savage driver (version 1.1.18 S3) for the last few days. I've been using a somewhat hackish setup, using - the 2D driver within a current CVS HEAD server; - the kernel module built from 4.2.0 sources and a heavily patched 2.4.18 kernel; - the 3D driver built from 4.2.0 sources but used with a 4.2.1 copy of Mesa (actually Debian's 4.2.1-6). I've got no idea whether the bugs I've encountered are due to my weird setup, or to S3's code. The hardware is a Savage Twister-K and a 950 MHz Duron. Nothing to say about 2D or Xv -- in normal usage, both appear to be as fast and stable as recent versions of Tim's driver. I didn't try to make XvMC work. At least on my setup, direct OpenGL is not ready for general usage. The most striking problem is that glBitmap and glDrawPixels (and hence glXUseXFont) are broken (glBitmap appears to do nothing, and glDrawPixels draws stuff at half the y coordinate). Hence, all applications and some games fail to show any text at all. (Most games appear to use textures for text.) The accumulation buffer appears to be broken too. While I haven't managed to make the system crash, it is quite easy to make the X server deadlock (having two threads do intensive OpenGL works every time). In all cases, I could reboot the machine remotely. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Rant (was Re: ATI Drivers.)
TR> Unfortunately, "interesting" and "meaningful" are NOT among the TR> criteria used by the US Patent and Trademark Office in awarding TR> patents. The European Parliament intends to discuss in September Arlene McCarthy's bill that aims to put European patent law in step with its American counterpart. If you agree with Tim and happen to live in the EU, please do write a friendly note to your Euro-MP before September. General page on software patents in the EU (including calendar): http://swpat.ffii.org An article by McCarthy: http://www.guardian.co.uk/online/story/0%2C3605%2C970294%2C00.html RMS' rebuttal: http://www.guardian.co.uk/online/story/0%2C3605%2C975126%2C00.html Sorry for the offtopic post. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: X.Org's IPv6 changes (was: CVS Update: xc (branch: trunk))
MLF> I think the best thing to do here is to recode DPS to rely on xtrans. Shall we remove libdps from the tree? Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Pfaedit-devel] Re: [forum] Re: Choosing an extension for bitmap-only SFNTs
GW> Is there a real need to distinguish between bitmap only and ouline GW> sfnts? I feel that having the same extension for bitmap and scalable fonts is confusing -- without a naming extension, you need tools such as ftdump to find out what your fonts are. GW> I presume that an .otb font would just have EBDT/EBLC and I should not GW> generate a dummy glyf/loca/EBSC? That was the initial plan, but I found out that having FreeType grok such fonts required more changes than David Turner was wililng to make in the 2.1.* series. So I'm generating a zero-length glyf and a one-entry loca. (No EBSC indeed.) On the other hand, the code will accept any font that FreeType 2.1.4 will recognise as a bitmap font. I originally tested with pfaedit-generated fonts, although I haven't tested against pfaedit recently. (Will do before release.) GW> I presume also that it should have a head table and not a bhed, and GW> EBDT/EBLC rather than bdat/bloc? That's what I'm doing, although I guess that bdat would work just as well. Thanks for your help, George. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [forum] Re: Choosing an extension for bitmap-only SFNTs
>> As far as I know, Microsoft doesn't use bitmap-only sfnts -- they use >> scalable fonts throughout, nowadays, only keeping the legacy .FON >> format for backwards compatibility. TR> Windows XP still has Terminal, Courier, MS Serif and MS Sans TR> Serif, all of which are bitmapped and in common use. Indeed, MS TR> Sans Serif is the default font for dialog boxes unless otherwise TR> overridden. They're still .FON files, not bitmap-only SFNTs. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [forum] Re: Choosing an extension for bitmap-only SFNTs
[XFree86 is switching to SFNT wrappers for bitmap fonts; what is a suitable extension? Adding the FreeType and PFAEdit lists in case they have something to say.] >> I need to pick an extension for the bitmap-only SFNT fonts After reading carefully the replies, the current front-runner is ``otb'', for ``OpenType Bitmap''. Is that extension used up yet? DD> With the proviso that there has been some research to determine that DD> nobody else is already using an extension for fonts like this, David, As far as I know, Microsoft doesn't use bitmap-only sfnts -- they use scalable fonts throughout, nowadays, only keeping the legacy .FON format for backwards compatibility. Apple did at some point use bitmap-only sfnts (albeit in a format slightly different from the one I'm using), but the MacOS file system doesn't use file extensions. They also used them on the Newton handheld, but I have no idea if the Newton has file extensions (or even if it has a file system). They also have a bizarre encoding of SFNTs on Mac OS X. The extension is ``.dfont'', and is not specific to bitmap-only fonts. If anyone knows of a system that does use file extensions and that does use bitmap-only SFNTs, I'm quite willing to be compatible. Failing that, we'll have to pick our own. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Fonts] Bitmap-only SFNTs: initial code in CVS
> 4. Convert all the fonts to bitmap-only sfnt, and give them the
>extension ttf (for now -- see my next message):
>
> $ for i in *.pcf; do fonttosfnt -o ${i%.pcf}.ttf $i ; done
> $ rm *.pcf
Sorry, forgot an important step: transcoded fonts should be removed,
on-the-fly transcoding will happen.
$ rm *-*-*.pcf
$ for i in *.pcf; do fonttosfnt -o ${i%.pcf}.ttf $i ; done
$ rm *.pcf
Juliusz
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Choosing an extension for bitmap-only SFNTs
I need to pick an extension for the bitmap-only SFNT fonts[1]. While these fonts use the same file format as TrueType and OpenType fonts, they do not fullfill the requirements of any of the four (!) TrueType specifications. Apple calls them ``sfnt-wrapped bitmap fonts'', pfaedit calls them ``bitmap-only TTF fonts'', and Microsoft do not call them at all. These fonts are refused by Windows XP. Because users expect files with a ttf or otf extension to contain scalable fonts, they need to have a different extension. Such fonts are used by Apple (who do not use file extensions), but not by Microsoft (who do); hence, I believe I need to pick a new one. I suggest they should have the extension ``.sfnt'', with ``.sfn'' being recognised for compatibility with 8+3 systems. Opinions collected so far: - David Dawes doesn't have an opinion either way, but he'd like me to consult with this list first. - Egbert Eich would prefer ``.sfn'' to be the default, as he believes this will lessen his support load. (He's probably right, but I dislike making MS-DOS the default.) I'll probably submit code to handle the new extension these next days, and would be glad to hear from you as soon as possible. Juliusz [1] http://www.pps.jussieu.fr/~jch/software/xfree86-bitmap-fonts.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Bitmap-only SFNTs: initial code in CVS
It is now possible to use bitmap-only SFNTs in XFree86. There is very
little left to do at the server level, some more work is needed at the
level of fonttosfnt and mkfontscale.
0. Check you've got the right version of XFree86.
$ cvs log xc/lib/font/fontfile/fontdir.c | grep 289
289. Twisting fontfile.c and fontdir.c to be able to pass all fonts (bitmap
1. Apply
http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=491
and rebuild mkfontscale.
2. Make a directory full of fonts.
$ cd /tmp
$ mkdir fonts
$ cd fonts
$ cp /usr/X11R6/lib/X11/fonts/misc/*.pcf.gz .
3. Uncompress the fonts. This is optional, but if you don't do that,
the next step will take minutes rather than seconds.
$ gzip -d *.pcf.gz
4. Convert all the fonts to bitmap-only sfnt, and give them the
extension ttf (for now -- see my next message):
$ for i in *.pcf; do fonttosfnt -o ${i%.pcf}.ttf $i ; done
$ rm *.pcf
You will get a number of failures, I'm looking into that.
5. Create a fonts.dir file:
$ mkfontscale -b
You'll get some warnings, and some of the generated names will not be
quite right. Additionally, all non-Unicode fonts will get names
ending in ``microsoft-symbol''. (Fixing that will require private
extensions to the sfnt format.)
6. Test the new fonts.
$ xset +fp `pwd`
$ xlsfonts -ll -fn '-misc-fixed-medium-r-normal--20-*-75-75-m-*-iso8859-1' | grep
RASTERIZER_NAME
RASTERIZER_NAME FreeType
$ xfd -fn '-misc-fixed-medium-r-normal--20-*-75-75-m-*-iso8859-1'
Juliusz
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Why lib/font/builtin is not useful -- yet
>> In the longer term, as client-side fonts become the norm, we could >> kill the core fonts system altogether and only keep the built-in fonts >> for compatibility with the protocol. EE> We cannot do this for people who rely on running legacy apps. Not arguing whether we actually want to do this, just saying 'tis an option to keep in mind. EE> We should then add one of these modules to the config files EE> generated by our configuration tools. We already include ``freetype'', I believe. Which is good for CVS, as it will help shaking bugs. (No opinion on what will happen in release.) Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Why lib/font/builtin is not useful -- yet
I'm currently in the process of changing somewhat the core bitmaps fonts system in order to simplify it and extend its functionality. Because the planned changes will break some users' configurations[1], David suggested that the core server should include Keith's ``builtin'' fonts, and that builtin should be implicitly added to the font path. Because builtin fonts include the fonts that the server absolutely needs to function (fixed and cursor), this would make sure that the server can start whatever the fonts (mis-)configuration. In the longer term, as client-side fonts become the norm, we could kill the core fonts system altogether and only keep the built-in fonts for compatibility with the protocol. Unfortunately, the built-in fonts code, in its current state, is not useful for that. Indeed, the current built-in code pulls in much of the PCF code (which is exactly what I'm in the process of eliminating), much of the local FPE code (which I hope to eliminate later), and much of the fontfile code (which must go at some point). In object-oriented terms, it inherits from the current (``legacy'') PCF code rather than being a completely independent implementation of the FPE interface. Rewriting built-in fonts from scratch in a manner such that they can be included in the core server would not be a big job, and I will be glad to help anyone who volunteers to do that. If nobody does, I'll probably do it at some point. For now, I'm going to break users' configurations without the ``builtin'' safety net. Watch this space for further updates[1]. Juliusz [1] I haven't quite made up my mind about how to handle it, but I expect that the ``bitmap'' module will no longer be loaded automatically. Thus, one day you'll cvs update, make World, and if you don't load either bitmap or freetype, stuff will break. If you explicitly load either bitmap or freetype, you should be fine. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Bugzilla #479: RFE: FreeType font engine should block opening
EE> Here is an issue for discussion from bugzilla (submitted by Roland EE> Mainz). Any opinions? Juliusz? I'm the author of this code, and obviously I disagree (otherwise I wouldn't have designed it this way). I don't feel strongly about it, though, and have no objection if you decide to change it. You'll note that the difference only happens if the user decides to create broken fonts.dir, so truly the point is of little import... Places to change if you decide to do so: - Type1/t1funcs.c, line 628; - FreeType/ftenc.c, line 107. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
>> From the code I don't see a difference in order between you version >> and Juliusz's either, am I wrong? KJ> No you're not. I didnt know if those semantics were important so I KJ> didn't change them. I am not sure they are important, but since this KJ> is a replacement for mkfontdir, I think it is prudent to err on the KJ> side of caution. I wouldn't bother. No strong objection, though. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
KJ> I am in favour (personally) of making -x mean "eXclude a suffix" KJ> and perhaps changing the current mkfontscale's -x to -a, for (a)dd KJ> an encoding. I agree. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Blame assignment [was: mkfontscale strikes again]
EE> So far submitted code was thoroughly tested... EE> I would like to get to a situation where the submitter himself EE> takes over more responsibilities and takes his code to a committable EE> state... I think that both should be available -- (1) the case when I take full responsibility for a patch and you trust me, and (2) the case when I don't feel competent and want you to double-check what I'm doing. We need some convention to distinguish between (1) and (2). The lkml, for example, use the phrase ``please apply'' to mark case (1). Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
RM> Weired. I don't see that problem when running "mkfontscale" RM> (Solaris2.7/SPARC build with Sun Workshop/Forte 7) ... Try -e. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
Please test http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=425 Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
AA> any idea whether this is the right solution ?
Please try the attached instead.
Juliusz
Index: xc/programs/mkfontscale/mkfontscale.c
===
RCS file: /cvs/xc/programs/mkfontscale/mkfontscale.c,v
retrieving revision 1.9
diff -u -r1.9 mkfontscale.c
--- xc/programs/mkfontscale/mkfontscale.c 2003/07/01 13:05:34 1.9
+++ xc/programs/mkfontscale/mkfontscale.c 2003/07/01 19:19:32
@@ -117,6 +117,7 @@
}
if(prefix[strlen(prefix) - 1] != '/')
strcat(prefix, "/");
+encodingPrefix = dsprintf("%s", prefix);
outfilename = NULL;
@@ -154,7 +155,8 @@
usage();
exit(1);
}
-strcpy(prefix, argv[argn + 1]);
+free(encodingPrefix);
+encodingPrefix = dsprintf("%s", argv[argn + 1]);
argn += 2;
} else if(strcmp(argv[argn], "-e") == 0) {
if(argn >= argc - 1) {
@@ -199,8 +201,6 @@
}
}
-encodingPrefix = dsprintf("%s", prefix);
-
if(outfilename == NULL) {
if(doBitmaps)
outfilename = "fonts.dir";
@@ -1211,10 +1211,12 @@
closedir(dirp);
return -1;
}
-free(fullname);
-fullname = n;
+encodingsToDo = listConsF(encodingsToDo, "%s %s", *name, n);
+free(n);
+} else {
+encodingsToDo =
+listConsF(encodingsToDo, "%s %s", *name, fullname);
}
-encodingsToDo = listConsF(encodingsToDo, "%s %s", *name ,fullname);
if(encodingsToDo == NULL) {
fprintf(stderr, "Couldn't allocate encodings\n");
closedir(dirp);
Re: mkfontscale strikes again
>> What sort of checking was done before replaceing mkfontdir with >> mkfontscale ? EE> I had the impression that this had been tested to some extend. Egbert, I am sorry if I misled you. I had tested the mkfontdir replacement on the font directories I hold on my laptop. I did not test this on a tree build, as building a tree on my laptop takes a long time and I was busy. It was my impression that I had been clear on this subject in bugzilla #388. http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=388 I'll try to be even more cautious in the future. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
AA> What sort of checking was done before replaceing mkfontdir with AA> mkfontscale ? None; there's been a problem of assignment of responsibility. Please see bug 388, where I'm assuming somebody will do the testing before committing (or decide not to commit until there's testing), and Egbert assumes I did the testing. AA> Is there a realistic prospect of testing and fixing this AA> properly within say a week ? I've scheduled Wednesday evening (CEST) for that. Might have some time tonight, no promises though. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: fonttosfnt portability patch
MH> Currently fonttosfnt doesn't compile on NetBSD, OpenBSD or Mac OS MH> X (and probably others) because it depends on which is a MH> linuxism. MH> I've created Bugzilla #433 with a proposed patch. Thanks. Please see bugzilla for minor comment. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Xv scaling and Savage
On a Savage, Xv appears to do nearest-neighbour scaling (blocky appearance). Is that a limitation of the hardware or a limitation of the driver? Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 1200dpi bitmap fonts in the tree
>> Is it me, or are we really shipping 1200dpi bitmap fonts as part of >> XFree86? AH> These have always been there. It's part of the Xprint server. At the very same time when the tree contains both (1) a Type 1 rasteriser and (2) a Type 1 version of Courier. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 1200dpi bitmap fonts in the tree
RM> The *.pmf files are no real fonts, they contain only the metrics for RM> printer builtin fonts That's not true. ftview 199 Courier.pmf (Make sure you've got the 2.1.4 version of ftview.) Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
1200dpi bitmap fonts in the tree
Is it me, or are we really shipping 1200dpi bitmap fonts as part of XFree86? xc/programs/Xserver/XpConfig/C/print/models/SPSPARC2/fonts/Courier.pmf Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Fonttosfnt: new version
On http://www.pps.jussieu.fr/~jch/software/files/fonttosfnt-20031304.tar.gz you will find a new version of fonttosfnt. Unlike previous versions, this version builds with an unadulterated copy of FreeType 2.1.4 (but nothing earlier). Unlike previous versions, it recodes non-Unicode bitmap fonts to Unicode, which should make them usable with fontconfig. I have not tried this myself, though, and would be very curious to hear from you if you do. Due to a bug still present in FreeType, it will only work with PCF fonts, not with BDF. Due to a different bug in FreeType, it will be *very* slow with compressed PCF fonts. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xterm in xfree86 4.3: warning
FL> newly built xfree86 4.3: FL> when I run xterm, it gives: FL> Warning: could not change ownership of tty -- pty is insecure! That's luit. FL> I tried with and without setuid-root, same problem. It's *luit* that must be setuid root, not XTerm. Note that due to a misunderstanding of saved-id semantics, the version of luit in 4.3 cannot be made setuid root on FreeBSD and NetBSD systems (OpenBSD is okay). I've submitted a fix, I don't know if it got in yet. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: X-Server segfault
MV>I believe this can only happen if your font render is broken. MV> These are fixed fonts. It should be impossible that there is no MV> data in those pointers. As mark says, we need to know the font type, the font rederer you are using, and the version of XFree86. A log file would help MV>Is this recent source code? There have been bugs of this sort MV> fixed in the font renderers not long before 4.3. Speaking of freetype only, this looks new to me. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Bitmap fonts update -- please test
Hello, On http://www.pps.jussieu.fr/~jch/software/files/freetype-bitmap-20030327.patch.gz you will find a patch that has the following effects: - makes the XFree86 server use the system-wide FreeType library rather than the one included with XFree86; - makes the FreeType backend grok bitmap fonts (BDF, PCF and sfnt-wrapped); - makes some minor changes to the fontdir logic to pass bitmap entries to scalable backends. The latter change is necessary because the bitmap entry points do not provide enough information to perform on-the-fly reencoding (or at least I think so). Keith, could you please check my changes to fontfile? Known bugs include the fact that it will only deal correctly with Unicode-encoded PCF fonts, due to a limitation of current versions of FreeType. It would deal correctly with BDF fonts, were it not for a different bug in FreeType. If you're courageous, you should be able to compile a server with this patch and with the legacy bitmap backends compiled out. Note, however, that doing that will currently break mkfontdir. Things remaining to do: - fix the issues with the FreeType libs; - fix fonttosfnt now that it can actually be used; - fix mkfontdir; - implement fontconfig-based FPEs. I'll be away from e-mail next week, so please don't worry if you receive no reply from me over that period. Regards, Juliusz P.S. David, it goes without saying that this patch is not ready to be committed. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Fontcache extension
I have the following problems with the fontcache extension: - it is linked into the core server; - it exposes to client-side stuff that client-side has no business knowing about; - it is used by no client; - it manages data structures that only the X-TT backend uses. In the light of the above, I would like to request that the X-TT developers should consider removing the fontcache extension, and migrating the code into the X-TT core. This would ensure that fontcache is restricted to exported ABIs, which would make my current work of streamlining fontlib somewhat easier. Thanks a lot, Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: http://www.xfree86.org/devel/ is gone?
DD> That is correct. Since this is a resource that contained DD> information that cannot be made publicly available, it has been DD> removed. Which means that we no longer have access to the patches@ and cvs-commit@ list archives? It doesn't make life much earlier. Followups (discouraged) to [EMAIL PROTECTED] Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
http://www.xfree86.org/devel/ is gone?
> Not Found > The requested URL /devel/ was not found on this server. > Apache/1.3.26 Server at www.xfree86.org Port 80 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Some patches to luit
IT> intro(2) manpage on Solaris, which said: IT> | effective user ID and effective group ID prior to an exec of Interesting. Which version of Solaris are you using? I think it must be a documentation bug; it appears to be fixed under 5.8. Check also the execve(2) page. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Some patches to luit
IT> I do not know what happens if luit with luit-freebsd.patch is IT> setuid'ed to a non-root user. >> It looks like it's a security hole on _POSIX_SAVED_IDS systems. I've just sent a patch to disable that case. If anybody complains, I can add code to use setresuid in that case. IT> I do not see how it can be. IT> Following is my understanding: suppose systems with POSIX-setuid. If IT> luit is setuid'ed to a non-root user, say, daemon, and a user called IT> tom launches it, luit runs with the real and saved UIDs tom and IT> effective UID daemon. I understand that suid is now daemon. The Linux man page is not quite clear about that, here's what the FreeBSD man page says: > After any set-user-ID and set-group-ID processing, the effective user > ID is recorded as the saved set-user-ID, And here's the SUSv4 wording: > The effective user ID and effective group ID of the new process > image are saved (as the saved set-user-ID and the saved set-group-ID > for use by setuid( ). IT> After setuid, the effective UID changes to tom, resulting in all IT> the three UIDs equal to the real UID. No, suid is still daemon. Fork, exec(/bin/sh), and the user can setuid(daemon). Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Some patches to luit
IT> On the default installation of FreeBSD 4.x, /dev does not have IT> pty[qrs]* device nodes. allocatePty in sys.c searches IT> /dev/pty[p-zP-T][0-9a-f], Actually, the problem is that allocatePty stops as soon as it encounters ENOENT on the assumption that there are no holes in the pty space. This assumption is wrong on recent FreeBSD, which has changed the names of ptys w.r.t. 4.4BSD. (Why?) I've fixed this by continuing searching when getting ENOENT, which should have no ill effects other than taking more time to fail when running out of ptys. That's patch 5674, by the way, it'd be nice if the various BSD maintainers (including Mac OS X) could have a look at it. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Some patches to luit
IT> I am fine if luit searches /dev/pty[p-zP-T][0-9a-v] instead of IT> /dev/pty[p-zP-T][0-9a-f]. Fine. I'll send a patch straight away. IT> From what I've learned from a quick search, FreeBSD's and POSIX's IT> setuid are different only when called from processes which are IT> setuid'ed to other user than root. Am I wrong? No, you're right. Sorry for that, I was confused; it looks actually like the 4.4BSD (not 4.3BSD) semantics makes more sense than the Posix saved IDs one. It looks like it's safe to remove the check for _POSIX_SAVED_IDS. I'll send a patch. IT> I do not know what happens if luit with luit-freebsd.patch is IT> setuid'ed to a non-root user. It looks like it's a security hole on _POSIX_SAVED_IDS systems. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xfree 4.2.x Radeon and gr security linux kernel
KK> (I'm still waiting for the xfree configuration option to KK> statically link in it's modules instead of dynamically loading KK> them). Eh? #define StaticServer YES. KK> I'm a teacher for programming and networking in a technical high KK> school. I've grades, exams and the like on this notebook, A student who's been able to break into your machine deserves an A. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Some patches to luit
Please don't apply. IT> It seems xc/programs/luit/sys.c in XFree86 4.3.0 contains a off-by-one IT> bug. A patch (sys.c.patch) to fix this is attached. This is correct. Thanks, I've forwarded it to the patchers. IT> - Make luit use openpty to search an unused pty. Without this patch, IT> luit aborts after opening ten or so xterms. Could you explain why this happens? allocatePty in sys.c searches through 256 ptys. I strongly dislike the openpty interface, which I feel is badly designed. Indeed, your patch causes luit to open the slave side in the parent, which feel wrong. Your patch also breaks support for systems with SVR4 ptys. This cannot go in. IT> - Allow one to setuid luit. This one is incorrect; it is a serious security hole, not only on FreeBSD but on all systems that have saved-ids that don't respect the Posix semantics. Luit will check for Posix saved IDs, and refuse to run if it's setuid on systems that have the (broken) 4.3BSD saved-ids semantics. Your patch merely removes this check. OpenBSD have done the reasonable thing, and abandoned the 4.3BSD saved-ids semantics in favour of the Posix one. FreeBSD haven't, however, and making luit setuid safely under FreeBSD would require using BSD-specific interfaces. This is *not* what you have done. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: embedded
Ciara, Tiny X is probably overkill for you. The server is 600 KB, but then you need the client libraries (at least 200 KB), and the clients themselves. Furthermore, Tiny X is currently for Linux only, which will restrict your choice of OS. Sorry if that's not particularly helpful, but I'm afraid you'll need to look somewhere else. Good luck, Juliusz P.S. Alexander, please do relax. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Half-QWERTY keyboard support: help!
JL> Can anybody point me to some really low-level place in the code where the JL> raw (or almost-raw) key codes get processed, so I can at least write a JL> patch to transform them in this sort of way: JL> http://repetae.net/~john/computer/hk/ I'm really not familiar with the input layer, and I don't claim that any of what follows is even remotely related to reality. The really low-level place appears to be stdReadInput in hw/xfree86/os-support/linux/lnx_kbd.c. It think it would be better to do a driver-independent job by hacking at xf86PostKeyEvent in hw/xfree86/common/xf86Xinput.c. This should work with all XFree86 drivers -- all the world is not Linux. An even better solution would be to work at DIX level (meaning that your code would work in all implementations of X11 known to man except one) by wrapping processInputProc somewhere or somewhere else, but I have absolutely no idea how to do that. Perhaps somebody can make a more useful suggestion. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Half-QWERTY keyboard support: help!
KT> If you defined SPACE to be third-level modificator instead of ralt, KT> then you could place mirrored keys into third-level and everything would KT> be easy. If you need to preserve alt, the task is somewhat harder. I suspect that the OP wanted space alone to still generate a space. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xf86cfg: ERROR SIGSEGV caught!
SD> some fonts can't be displayed any more which worked with freetype1 SD> based freetype module Yes. The FreeType 1 library had been fine-tuned to include workarounds for a number of common font bugs (much against David Turner's preferences). These hacks are only now getting into FreeType 2. Now that 4.3 is out, I hope we'll be able to upgrade to 2.1.4; when that happens, I'll be very keen on bug reports describing such failures. Please do not send such bug reports now -- we do know that the version of FreeType included in 4.3 has some limitations. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Stepping outside the box with XAA drivers?
MV> but XAA is an all or nothing thing. Could you please explain that? Do you mean that if you use XAA, you can no longer wrap at the GCOps level? Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Interesting job control bug
>> I might very well change the default behaviour to quit if the child is ^ >> dead *and* the input buffer is empty. MF> The input buffer is probably empty. But the child isn't dead. MF> And without "-x" luit doesn't exit. That's something I *might* *perhaps* do *after 4.3*. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Interesting job control bug
>> Luit does things differently -- it waits until it gets an EIO on the >> master side of the pty. This means that if processes other than >> luit's child have a handle on the slave side tty, luit will keep >> running. MF> Why should this be useful? You're running in a UTF-8 locale, and find a directory where the filenames are in ISO 8859-1. You do $ LC_ALL=en_US luit ls Ls puts its input into the pty's buffer, then quits. Depending on how lucky you are with scheduling, luit might get the SIGCLD before it deals with ls's output. Heisenbug. I might very well change the default behaviour to quit if the child is dead *and* the input buffer is empty. It will still cause luit to hang if you do something that generates output faster than luit can push it around, for example $ tail -f /dev/zero & $ exit I didn't want to make such a change at this date, as it would require adding one new function to the portability layer (sys.c), which always makes me nervous. (If you look at the cvs log of sys.c, you'll see comments such as ``With any luck, this might even compile for a change...''. Being portable is fun, especially just before releases.) (The interface needed is poll/select with a zero timeout, assuming that zero timeouts have portable behaviour across all the systems that we support. Failing that, it's poll/select with a 10ms timeout, assuming that 10ms..., well, never mind.) (I was going to continue with an essay on the subject of the POSIX tty interface, but then decided that the list's honourable readership might be getting bored by now.) (Multiple bracketed paragraphs usually indicate a severe lack of focus.) MF> Maybe it would be useful if luit had X-Resources to set default values MF> for it's options? Or maybe an additional option/resource for xterm MF> where one can specify options for the localeFilter? I agree, and by default XTerm should invoke luit with -x. Not for 4.3, though. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Luit documentation update and minor patch
- The most typical use of .B luit is to adapt an instance of .B XTerm ! in UTF-8 mode to the locale's encoding. For most locales, this ! doesn't require using any flags: .IP $ xterm \-u8 \-e luit .PP ! ! .B Luit ! may also be used with applications that hard-wire an encoding that is ! different from the one normally used on the system. In order to use ! such applications, you will need to directly manipulate ! .BR luit 's ! ISO\ 2022 state: .IP ! $ xterm \-u8 \-e luit \-g2 'CP 1252' .PP ! The ! .B \-v ! flag may be used in order to examine ! .BR luit 's ! initial state. ! ! Future versions of ! .B XTerm ! will automatically invoke .B luit ! when necessary. ! .SH FILES - .TP .B __projectroot__/lib/X11/fonts/encodings/encodings.dir The system-wide encodings directory. - .TP .B __projectroot__/lib/X11/locale/locale.alias The file mapping locales to locale encodings. - .SH SECURITY - On systems with SVR4 (``Unix-98'') ptys (Linux version 2.2 and later, SVR4), .B luit --- 134,188 .TP .B \-\- End of options. .SH EXAMPLES The most typical use of .B luit is to adapt an instance of .B XTerm ! to the locale's encoding. Current versions of ! .B XTerm ! invoke ! .B luit ! automatically when it is needed. If you are using an older release of ! .BR XTerm , ! or a different terminal emulator, you may invoke ! .B luit ! manually: .IP $ xterm \-u8 \-e luit .PP ! If you are running in a UTF-8 locale but need to access a remote ! machine that doesn't support UTF-8, ! .B luit ! can adapt the remote output to your terminal: .IP ! $ LC_ALL=fr_FR luit ssh legacy-machine .PP ! .B Luit ! is also useful with applications that hard-wire an encoding that is ! different from the one normally used on the system or want to use ! legacy escape sequences for multilingual output. In particular, ! versions of ! .B Emacs ! that do not speak UTF-8 well can use .B luit ! for multilingual output: ! .IP ! $ luit -encoding 'ISO 8859-1' emacs -nw ! .PP ! And then, in ! .BR Emacs , ! .IP ! M-x set-terminal-coding-system RET iso-2022-8bit-ss2 RET ! .PP .SH FILES .TP .B __projectroot__/lib/X11/fonts/encodings/encodings.dir The system-wide encodings directory. .TP .B __projectroot__/lib/X11/locale/locale.alias The file mapping locales to locale encodings. .SH SECURITY On systems with SVR4 (``Unix-98'') ptys (Linux version 2.2 and later, SVR4), .B luit *** *** 195,201 .B Luit will refuse to run if it is installed setuid and the underlying system does not have POSIX saved ids. - .SH BUGS None of this complexity should be necessary. Stateless UTF-8 throughout the system is the way to go. --- 204,209 *** *** 204,215 Selecting alternate sets of control characters is not supported and will never be. - .SH SEE ALSO xterm(1), unicode(7), utf-8(7), charsets(7). .I Character Code Structure and Extension Techniques (ISO\ 2022, ECMA-35). .I Control Functions for Coded Character Sets (ISO\ 6429, ECMA-48). - .SH AUTHOR Luit was written by Juliusz Chroboczek <[EMAIL PROTECTED]> for the XFree86 project. --- 212,221
Re: Interesting job control bug
>> The xterm window doesn't close. As soon as the tail is killed, the >> xterm closes. It wasn't a bug after all, luit is working as designed. XTerm shuts down as soon as the child dies. This means that XTerm will discard any of the child's output that may have been queued in the pty. Luit does things differently -- it waits until it gets an EIO on the master side of the pty. This means that if processes other than luit's child have a handle on the slave side tty, luit will keep running. In another message (``Luit documentation update and minor patch''), I add an option ``-x'' to luit that causes it to work like xterm. With this patch, if you do $ luit -x ls there's a good chance luit will display nothing, depending on how the child gets scheduled. Whether XTerm should, by default, invoke luit with the ``-x'' flag is a different question. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XFree86 CVS procedures [was: Driver for CVS?]
TZ> But with your answers I can never understand your way of working; Okay, here's how it works. Everyone has read access to XFree86 CVS (see the www.xfree86.org page for details), and most developers keep a private XFree86 CVS tree, which they keep up to date using either cvs or cvsup. As you work, you make the modifications to your private tree, and test them locally or by passing them on to the list. When you're happy with your changes, you cvs diff and send a patch to the right address, together with an explanation. The patch gets reviewed by the Old and the Wise, who either commit it or else get back to you. It is important to realise that all commits are accompanied with a change to the CHANGELOG file. Determining who is guilty for a given change is as simple as cvs diff CHANGELOG. If you have a problem with a change, you get in touch with the person credited in the CHANGELOG, not with the committer. In my experience, the system works reasonably well, except when committers are busy. Usually, a well-explained patch gets committed with no comment; in the few cases when the committer objected, he either convinced me that my approach was wrong, or else requested some minor changes to the code. When the committers get busy with other things, work on XFree86 becomes absolute hell, as your private CVS tree gets increasingly out of sync with the official tree, and generating patches to share becomes extremely painful. This happened last spring for a few months, and I hope it doesn't happen again soon. I hope this clarifies things, Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Interesting job control bug
I've received the following, which puzzles me.
> Start an xterm with luit (non-UTF-8 locale and "-lc" option or locale
> resource set to "true"):
>
> mfabian@magellan:~$ LANG=en_US xterm -lc &
>
> Within this xterm, do
>
> mfabian@magellan:~$ tail -f /etc/X11/XF86Config&
> [1] 19859
> mfabian@magellan:~$ InputDevice "Mouse[1]" "CorePointer"
> [...]
>
> Exit the shell in this xterm using "Control-d":
>
> mfabian@magellan:~$ exit
>
> The xterm window doesn't close. As soon as the tail is killed, the
> xterm closes.
Here's a paraphrase of the code that takes care of setting up the
child's terminal (error checking omitted). Anyone got an idea what
I'm missing?
pid = fork();
...
if(pid == 0) {
close(pty); /* master */
close(0);
close(1);
close(2);
pgrp = setsid();
tty = open(..., O_RDWI | O_NOCTTY); /* pty slave */
#ifdef TIOCSTTY
rc = ioctl(tty, TIOCSCTTY, (char*)0);
#endif
#ifdef SVR4
ioctl(tty, I_PUSH, "ptem");
ioctl(tty, I_PUSH, "ldterm");
ioctl(tty, I_PUSH, "ttcompat");
#endif
dup2(tty, 0);
dup2(tty, 1);
dup2(tty, 2);
if(tty > 2) close(tty);
execvp(...)
} else {
/* nothing interesting */
}
Juliusz
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: xterm and UTF8
JG> Though I disagree that ssh should not transmit the current locale: it JG> _should_, precisely because it could be different coming from Solaris, JG> or Debian, or Windows, and you want to make sure both sides agree on JG> the encoding. Of course, this also assumes that there is some suitable JG> locale conversion that can take place; otherwise the whole exercise is JG> pointless [such as an English locale user ssh'ing into a Japanese box]. Another solution would be to use UTF-8 as the wire encoding, and have the local and remote ssh implementations do all conversion to the local encodings. Kermit does exactly that (optionally). If you know that your local terminal groks UTF-8, you can simulate the functionality by typing luit first thing when you login. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xterm and UTF8
>> And, yes, of course xterm should start up in utf-8 mode if the locale >> encoding is UTF-8. MH> Thanks, that was my original conclusion also. I had just MH> wondered why it doesn't. Just an xterm bug I guess. *locale: true (Credit to Tomohiro Kubota.) Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
Oh, and what about the Savage changes? XFree86 no longer crashes the TwisterK, which is important for a lot of people. Unless Tim is around, here's my proposal: Fixes Savage problems on the TwisterK, including hangs in the Blaster xscreensaver hack and hangs with XVideo. Also fixes incorrect memory size detection. (There's probably more, but that's the ones that were biting me.) Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
AH> Here's a list of items for the RELNOTES for 4.3.0, if anyone has anything AH> to add to this, please send it in. Partial rewrite of the ``freetype'' backend. The new version is based on FreeType 2, and handles TrueType (including OpenType/TTF), OpenType/CFF and Type 1 fonts. The old ``type1'' font backend is deprecated, and only used for CIDFonts by default. Inclusion of a new utility, ``mkfontscale'', for building fonts.scale files. (The following point is due to Keith Packard, but here's a suggestion in case he doesn't chime in himself.) Major restructuring of the Xft (server-side fonts) library. Xft is now split into fontconfig, which deals with font discovery and configuration and is independent from X, and Xft itself, which uses fontconfig and deals with font rasterisation and rendering. The format of Xft font configuration files has changed in an incompatible manner. (There's also been a number of changes to Xkb which I haven't been following closely. Ivan?) Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: I'm stuck: font-related crash with current CVS
KP> but I'm afraid we'll still have segfaults from the setjmp/longjmp KP> issue. Why's that? Is setjmp/longjmp verboten in modules, or is FreeType doing something non-portable? Something that you've suggested before, and that I'm inclined to do after 4.3, is to link (dynamically) the core server with FreeType, and make a subset of FreeType an optional part of the fonts interface for modules. The FreeType module would refuse to load in a server that doesn't provide FreeType. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: I'm stuck: font-related crash with current CVS
MF> Caslon fonts (same problem): Hold on... I'm seeing a crash with the Caslon fonts. Are you seeing something else? Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
I'm stuck: font-related crash with current CVS
Mike has reported to me a crash with the new FreeType backend and the Caslon fonts included with SuSE. (Mike, could you be so kind as to follow up with a stable URL for the fonts?) I'm stuck. The problem doesn't happen with xfs, and it doesn't happen with a monolithic server. So it must be in some way related to the module loader. A couple of hours of printf-based debugging got me to the point where the crash happens within the FreeType library. I've been unable to make the loader-aware debugger work on my system (crashes at startup, and the osource won't build). If anyone can help, please do. (David, does that count as a release-critical bug?) Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SunRay driver for XFree86
Hi Markus, That's good to hear. I'll be glad to read through your docs when I have some time. MK> So the question I'd like to ask here is, can someone provide us with a MK> few pointers to get started with understanding how a SunRay driver could/ MK> should possibly interface with the XFree86 X server. I think you want to start with a dumb X server with either Mark's or Keith's shadowfb code. You'd simply blit to the FreeRay in the shadowfb update code. If the 'Ray provides primitives for Screen->Screen blits or similar, you'd probably also want to wrap some of the GCOps after they get through shadowfb. /I/'d start with the KDrive server and either of the fbdev or the vesa drivers and then change all the accel code. But I know that some people on this list would differ. Good luck, Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.2.99.4 snapshot tagged
Try setting XCURSOR_CORE=1. Also try XCURSOR_THEME=whiteglass. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Possible Xcursor bug
I've sent this to Xpert yesterday, didn't seem to get through, I'll try Devel today. I've found that in order to use core cursors, I need to set XCURSOR_CORE in *both* Xdm's environment and the window manager's environment. If the windows manager uses themed cursors, setting XCURSOR_CORE in a client's environment appears to have no effect -- is there some sort of weird inheritance going on? (XCURSOR_THEME works fine.) It is my understanding that setting XCURSOR_CORE disables RGBA cursors altogether. What I'd like to have is the ability to disable core cursor theming while retaining the ability to use RGBA cursors in clients that explicitly request them using the Xcursor library. Unless I've missed something, there's no such ability currently. It think that setting XCURSOR_THEME=none would be a reasonable syntax for that. Finally, I think that we need an Xcursor theme, call it ``classic'', that consists of the traditional core cursors albeit with a slight shadow. I'll try to conjure a utility to build that, but will probably not have the time before 4.3, and I'd love to see someone beat me to it. Julisuz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
