Re: xterm can hang, CPU bound
On Mon, 3 Feb 2003, D. Hugh Redelmeier wrote:
| I guess the comparable chunks are like this:
|
| select(6, [4 5], [], NULL, {0, 0}) = 1 (in [4], left {0, 0})
| select(5, [4], [], [], {0, 0}) = 1 (in [4], left {0, 0})
| select(5, [4], [], [], {0, 0}) = 1 (in [4], left {0, 0})
| select(5, [4], [], [], {0, 0}) = 1 (in [4], left {0, 0})
That sure looks like it ought to eat all available CPU.
None of those calls should block.
well - it didn't. I was watching both xload and top. on the redhat8, I
could see that it fell into a pattern that eventually blew up, but not
on the slackware71.
| | What do you think about the approach I suggested (act as if a default
| | CSI...T sequence had been received until the real one is)? Perhaps
| | the default should only be used after some timeout.
| |
| | it's not entirely clear to me what the sequence would be here.
|
| Two obvious ones: the whole xterm region, or an empty region at the
| point of the cursor. I'd vote for the empty region: no information
| about a subsequent click is lost (the answer will be forced to be the
| long form).
|
| Clearly func should be non zero in either case: we don't want to
| cancel the mode.
|
| I do suggest that the default only be installed after a brief timeout.
| How long? A tenth of a second feels about right.
|
| I also suggest that the default be replaced if and when the explicit
| CSI...T sequence is received.
|
| It sounds as if you're proposing to make it return a dummy escape sequence -
| or make the escape sequence terminate automatically after a short time -
| but it's not clear to me
Sorry, I'll try to be clearer.
When a button is pressed in mouse hilite tracking mode,
xterm sends ESC [ M Cb Cx Cy to the PTY
xterm awaits ESC ... T from the PTY, doing nothing else.
The ESC [ Ps ; Ps ; Ps ; Ps ; Ps T informs xterm:
func: non zero to initiate hilite tracking and 0 to abort
startx, starty: starting location for highlighted region
firstrow, lastrow: limits for tracking
I'm proposing that until the ESC ... T message is received from
through the PTY, the xterm should act as if it had received something
like: ESC [ 1 ; curx ; cury ; currow ; currow T
This would be provisional. When (if) an ESC ... T is actually received,
it should override this default.
ok - I can see what you're asking (sounds reasonable).
--
T.E.Dickey [EMAIL PROTECTED]
http://invisible-island.net
ftp://invisible-island.net
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: [Bug 83284] New: Mouse cursor visual glitches with XFree86 (fwd)
RADEONWaitForVerticalSync() polls for. I'm working on a fix, basically
my plan is to use the DRM vertical blank ioctl when appropriate.
There is a patch I posted a while ago for the same problem that waits for
retrace with a timeout - so even if the bit is cleared we timeout after
1/60 of sec (approx) and everything is fine anyway.
I don't like that. Polling for CRTC{,2}_VBLANK_SAVE should be foolproof,
or am I missing something?
But these bits are cleared by DRM driver to acknowledge an interrupt.
Also, Michel, while you are at it - could you modify the irq handler in
DRM to *only* clear bits that it is actually interested it ? Otherwise it
clears capture and gui_dma IRQs which GATOS km driver needs and which are
not used by drm at all.
I wouldn't mind doing that at all, in fact that's how I did it
initially, but the code has since been changed with the following
comment:
/* Acknowledge all the bits in GEN_INT_STATUS -- seem to get
* more than we asked for...
*/
Your argument makes a lot of sense so I'll probably change it back in
DRI CVS, but I don't know if it'll make it for 4.3.0...
The thing is that we should not be getting any extra bits unless we (or
someone else like GATOS km) has asked for them. This makes sense as if
there was a bit set causing an interrupt before drm driver loaded and
nobody was servicing it the system would lock up.
The reason there are extra interrupts without km loaded is likely due to
IRQ sharing.
The simplest way would be to define a mask of interrupts and AND it with
the current values of GEN_INT_CNTL before clearing acknowledge bits.
best
Vladimir Dergachev
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: A bug in xset and a fix for it
On Tue, Feb 04, 2003 at 05:15:59PM +0100, Tapani Utriainen wrote: Hi, currently xset can segfault when trying change the repeat rate using XKB. The problem is a missing null-pointer check and the fix is a one-liner appended below. I have no idea whether this is only an linux x86 issue since that is the only X-platform with XKB I have access to. Since the null pointer is dereferenced I can't see how this patch could break another platform. Have you looked into why XkbGetKeyboard() is returning NULL? David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XCursor: left_ptr_watch does not change with theme
On Tue, 2003-02-04 at 00:04, Brandon Wright wrote: With my attempts at theming Xcursor I have run into a deadlock. No matter what themes I use or create, none of them correctly change left_ptr_watch. Instead, the theme will default onto the left_ptr_watch from whiteglass. I did notice that in xc/lib/Xcursor/library.c that left_ptr_watch seems to be missing from the array that contains the other defined cursors. left_ptr_watch isn't a standard X cursor. Instead, the way it works is that when Xlib gets a request to create a bitmap cursor, libXcursor creates a hash value from the bits, and sees if there is a cursor with that hash value as a name. This hack allows libXcursor to theme custom bitmap cursors from programs like Mozilla. So, your theme needs a symlink: [big long string of hex digts] = left_ptr_watch see the existing themes for how the right name. Regards, Owen [ There is an environment variable you can set to trace what the cursors and hash values are that a program is creating, if you want to figure it out the name for other bitmap cursors. Search for getenv in the Xcursor sources ] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] 4.2.99.4 no display, locked keyboard (Radeon7500Mobility)
Michel, could you remind me what is that xxx_SAVE bit ? best Vladimir Dergachev On Sun, 3 Feb 2003, Michel [ISO-8859-1] Dänzer wrote: On Son, 2003-02-02 at 12:51, Michel Dänzer wrote: On Son, 2003-02-02 at 06:09, hy0 wrote: Judging from current situation, we probably should take RADEONWaitForVerticalSync and RADEONWaitForVerticalSync2 all out of the cursor routines. I'd prefer fixing those functions instead. After some more thought, polling for _VBLANK_SAVE in both is probably safest for 4.3.0. Here's what I'm talking about, what do you think? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: A question about this list
On Tue, 2003-02-04 at 15:21, Havoc Pennington wrote: On Tue, Feb 04, 2003 at 03:16:16PM -0300, Individual . . wrote: I joined this list because I have started programming with xlib.The questions I will probably ask will be quite basic. Is this a good list for this purpose? I googled quite a bit but could not find a mailing list dealing exclusively with programming for X11 for beginners. If anyone thinks I should try another list, I'd he happy to hear suggestions. Lesson one of programming with Xlib: 1. Don't. Use a GUI toolkit. Phew, the period after Don't came up very fine in my evolution. Kept staring at the sentence for a minut before I could get what you really mean :)) ;-) But, seriously. Havoc ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: A question about this list
On Tue, 4 Feb 2003 18:21:52 -0500 Havoc Pennington [EMAIL PROTECTED] babbled: On Tue, Feb 04, 2003 at 03:16:16PM -0300, Individual . . wrote: I joined this list because I have started programming with xlib.The questions I will probably ask will be quite basic. Is this a good list for this purpose? I googled quite a bit but could not find a mailing list dealing exclusively with programming for X11 for beginners. If anyone thinks I should try another list, I'd he happy to hear suggestions. Lesson one of programming with Xlib: 1. Don't. Use a GUI toolkit. ;-) But, seriously. well devel is more for development of xfree86 itself and the libs, not for helping people learn xlib programming as such. i know of no dedicated lists for this. to a small extent i agree with havoc. this is xlib. it's not a walk in the park. but on the other hand - it depends what you want to achieve. if you goal is to learn xlib so you can write your own toolkit or write things as close to the metal as possible for speed/efficiency reasons, or because you want to help with toolkit development - great. if you want to achieve a lot in a short space of time... forget it. main uses of xlib: * writing window managers * writing toolkits * insane monkeys * writing really small simple display programs that must require as little on the host system as possible. * testing x itself for performance/bugs * getting headaches maybe a few others... :) basically no book i've found is a REALLY good source of learning xlib - they cover some parts and skip others, none give you any real good tips and you generally need to have read a few good general graphics books first (ones that just deal with graphics algorithms and implementation) and combine this with what you can glean from a few xlib books and then the rest coming from the x manual pages, x header files and large chunks of existing x code out there. its very much a black art not many people get completely at home with and even fewer completely understand. -- --- Codito, ergo sum - I code, therefore I am The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] [EMAIL PROTECTED] Mobile Phone: +61 (0)413 451 899Home Phone: 02 9698 8615 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: A question about this list
On Tuesday, February 4, 2003, at 08:42 PM, Carsten Haitzler (The Rasterman) wrote: main uses of xlib: * writing window managers * writing toolkits * insane monkeys * writing really small simple display programs that must require as little on the host system as possible. BINGO! Yes, that's it, exactly. What is not helping me is that I am not a programmer, I am a person that likes programming and then sets himself these tasks and tries to achieve them based upon tutorials and simple examples (reprehensible, I know!) My first goal is to add a display function to a C++ class of mine that works with PNG images. It already relies on libpng, and I wanted to try and do it with xlib, instead of Gtk (more people will have X11 installed than those who have Gtk). Thanks for the comments. Paul ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: A bug in xset and a fix for it
On Tue, Feb 04, 2003 at 07:18:15PM +0100, Tapani Utriainen wrote: On Tue, 4 Feb 2003, David Dawes wrote: Have you looked into why XkbGetKeyboard() is returning NULL? Only briefly, the trail of the error led to a so dark place that I didn't dare to enter it :-) XkbGetKeyboard() calls XkbGetKeyboardByName(). That in turn uses _XReply() to fill in a xkbGetKbdByNameReply struct, and either that call fails, or the reported field of the struct is set to zero. (line 142 in XKBGetByName.c) Does the xset call actually change the repeat rate when this happens (with your fix)? Also, do you need to do anything special to reproduce this? A check for a NULL return value from XkbGetKeyboard() should be added (and I'll do that), but I'm wondering what ignoring it might be covering up. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: ANSI trigraphs enabled by default in X sources
On Mon, 3 Feb 2003, Keith Packard wrote: Is there anywhere in the X source code that *gasp* uses ANSI trigraphs and relies on this broken^Wwonderful feature of ANSI C being enabled? ;o) I sure hope not. I've certainly never seen any such code (and would have fixed it if I had). I'm wondering wether disabling trigraphs by default in stock sources is considered OK, or if I should have my patch escape the trigraph sequences to not be tokenized instead? You should fix your patch to not use that trigraph. Does GCC have a mode that pukes if it finds any trigraphs? That would be a better option than disabling them; X gets built with other compilers still, some of which might not have an option to disable trigraphs. Yeppers, that's the most sensible solution, and the one I've decided to take as well. Thanks for the feedback Keith -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
