home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / windows / x / 15657 < prev    next >
Encoding:
Text File  |  1992-08-26  |  2.8 KB  |  73 lines
  1. Newsgroups: comp.windows.x
  2. Path: sparky!uunet!munnari.oz.au!metro!news
  3. From: dawes@physics.su.OZ.AU (David Dawes)
  4. Subject: XPutImage and server with bit_order!=byte_order
  5. Message-ID: <1992Aug26.143515.24065@ucc.su.OZ.AU>
  6. Sender: news@ucc.su.OZ.AU
  7. Nntp-Posting-Host: physics.su.oz.au
  8. Organization: School of Physics, University of Sydney, Australia
  9. Date: Wed, 26 Aug 1992 14:35:15 GMT
  10. Lines: 61
  11.  
  12. I've been working on a mono VGA version of X386.  The 386 has a little
  13. endian byte-order, but the VGA's mono frame buffer uses a big endian bit-order.
  14. The mfb code can handle this, but there seems to be a problem with
  15. the conversions done in XPutImage (Xlib).
  16.  
  17. I've looked at the code -- and the reasoning given in XPutImage.c, and I
  18. believe there is a problem.
  19.  
  20. Here is an extract:
  21.  
  22. -> The following table gives the bit ordering within bytes (when accessed
  23. -> sequentially) for a scanline containing 32 bits, with bits numbered 0 to
  24. -> 31, where bit 0 should be leftmost on the display.  For a given byte
  25. -> labelled A-B, A is for the most significant bit of the byte, and B is
  26. -> for the least significant bit.
  27. -> 
  28. -> legend:
  29. ->         1   scanline-unit = 8
  30. ->         2   scanline-unit = 16
  31. ->         4   scanline-unit = 32
  32. ->         M   byte-order = MostSignificant
  33. ->         L   byte-order = LeastSignificant
  34. ->         m   bit-order = MostSignificant
  35. ->         l   bit-order = LeastSignificant
  36. -> 
  37. -> 
  38. -> format  ordering
  39. -> 
  40. -> 1Mm     00-07 08-15 16-23 24-31
  41. -> 2Mm     00-07 08-15 16-23 24-31
  42. -> 4Mm     00-07 08-15 16-23 24-31
  43. -> 1Ml     07-00 15-08 23-16 31-24
  44. -> 2Ml     15-08 07-00 31-24 23-16
  45. -> 4Ml     31-24 23-16 15-08 07-00
  46. -> 1Lm     00-07 08-15 16-23 24-31
  47. -> 2Lm     08-15 00-07 24-31 16-23
  48. -> 4Lm     24-31 16-23 08-15 00-07
  49. -> 1Ll     07-00 15-08 23-16 31-24
  50. -> 2Ll     07-00 15-08 23-16 31-24
  51. -> 4Ll     07-00 15-08 23-16 31-24
  52.  
  53. It seems to me that the lines for 2Ml, 4Ml, 2Lm, 4Lm are not correct.
  54. The only difference between 1Ll and 1Lm is that the bit order within
  55. each byte is reversed.  The same is true for 4Ll and 4Lm (at least
  56. that's how the mfb code works).  Why then is the ordering given for 1Lm
  57. different to that for 4Lm when 1Ll and 4Ll are the same?  The above
  58. table is showing the byte order reversed as well as the bit order (and
  59. this is what is causing problems with the mono VGA server which uses
  60. bitmaps of the 4Lm type).
  61.  
  62. Is there something that I'm missing?
  63.  
  64. (Modifying XPutImage along these lines fixes the problem -- but the server
  65. will have problems with clients built with the unmodified version.)
  66.  
  67. David
  68. --
  69. ------------------------------------------------------------------------------
  70.  David Dawes (dawes@physics.su.oz.au)    DoD#210      | Phone: +61 2 692 2639
  71.  School of Physics, University of Sydney, Australia   | Fax:   +61 2 660 2903
  72. ------------------------------------------------------------------------------
  73.