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: 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?
JWI'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 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 [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: 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 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: 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
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: 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: 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: 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]
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: (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: 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: 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: 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: 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: 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: 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: 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 stdjmp.h. 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: XFree86 over Firewire !
RFC 872. 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: [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: [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: 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: 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
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
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
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
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
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
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
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
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: 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 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
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: fonttosfnt portability patch
MH Currently fonttosfnt doesn't compile on NetBSD, OpenBSD or Mac OS MH X (and probably others) because it depends on byteswap.h 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
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
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
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
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
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
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
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: 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: 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: 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: 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: 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: 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
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
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: 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
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
