Qt-interest Archive, December 2000
Re: Qt/Embedded on grey-scale LCD display
Message 1 in thread
On Wed, 29 Nov 2000 12:21, Cliff wrote:
> As I know, the Qt/embedded is not support on 4bpp (or 16 grey-level) Linux
> framebuffer .
> The processor that I am using is Cirrus Logic EP 7211, it has built-in LCD
> controller with
> bit per pixel programmable for 1,2 or 4 bit.
> Is there any work around if I want to run Qt/Embedded using this
> controller?
You can now get a patch for 4bpp greyscale support from:
ftp://ftp.trolltech.com/qt/source/qt-embedded-2.2.2-4bpp_grey.diff.gz
I do not have any 4bpp hardware to test on (I developed using the
virtual framebuffer) so I would appreciate any feedback.
Best Regards,
Martin.
--
[ signature omitted ]
Message 2 in thread
Dear Martin,
Are there any QVFB patch for supporting 4bpp grey scale?
Best Regards,
Cliff
>I have made a patch for 4bpp greyscale support available from:
>
>ftp://ftp.trolltech.com/qt/source/qt-embedded-2.2.2-4bpp_grey.diff.gz
>
>I do not have any 4bpp hardware to test on (I developed using the
>virtual framebuffer) so I would appreciate any feedback.
>
>Best Regards,
>Martin.
>
>--
>Martin R. Jones
>mjones@trolltech.com
>Trolltech Australia
Message 3 in thread
On Mon, 4 Dec 2000 11:23, Cliff wrote:
> Dear Martin,
>
> Are there any QVFB patch for supporting 4bpp grey scale?
Yes, small enough to be included here:
diff -u /home/mjones/test/qt-2.2.2/tools/qvfb/qvfbview.cpp ./qvfbview.cpp
--- /home/mjones/test/qt-2.2.2/tools/qvfb/qvfbview.cpp Tue Sep 12 11:41:53
2000
+++ ./qvfbview.cpp Mon Dec 4 10:16:09 2000
@@ -48,6 +49,7 @@
switch ( d ) {
case 1:
+ case 4:
case 8:
case 32:
break;
@@ -222,6 +245,45 @@
unlock();
}
+QImage QVFbView::getBuffer( const QRect &r, int &leading )
+{
+ if ( hdr->depth == 1 || hdr->depth >= 8 ) {
+ leading = r.x();
+ return QImage( data + hdr->dataoffset + r.y() * hdr->linestep,
+ hdr->width, r.height(), hdr->depth, hdr->clut,
+ hdr->depth == 1 ? 0 : 256, QImage::LittleEndian );
+ } else if ( hdr->depth == 4 ) {
+ static unsigned char *imgData = 0;
+ if ( !imgData ) {
+ int bpl = ((hdr->width*8+31)/32)*4;
+ imgData = new unsigned char [ bpl * hdr->height ];
+ }
+ QImage img( imgData, r.width(), r.height(), 8, hdr->clut, 16,
+ QImage::IgnoreEndian );
+ for ( int row = 0; row < r.height(); row++ ) {
+ unsigned char *dptr = img.scanLine( row );
+ unsigned char *sptr = data + hdr->dataoffset +
(r.y()+row)*hdr->linestep;
+ sptr += r.x()/2;
+ int col = 0;
+ if ( r.x() & 1 ) {
+ *dptr++ = *sptr++ >> 4;
+ col++;
+ }
+ for ( ; col < r.width()-1; col+=2 ) {
+ unsigned char s = *sptr++;
+ *dptr++ = s & 0x0f;
+ *dptr++ = s >> 4;
+ }
+ if ( !(r.right() & 1) )
+ *dptr = *sptr & 0x0f;
+ }
+ leading = 0;
+ return img;
+ }
+
+ return QImage();
+}
+
void QVFbView::drawScreen()
{
QPainter p( viewport() );
@@ -243,9 +305,8 @@
r.rRight() = QMIN(r.right(),hdr->width-1);
r.rBottom() = QMIN(r.bottom(),hdr->height-1);
}
- QImage img( data + hdr->dataoffset + r.y() * hdr->linestep,
- hdr->width, r.height(), hdr->depth, hdr->clut,
- hdr->depth == 1 ? 0 : 256, QImage::LittleEndian );
+ int leading;
+ QImage img( getBuffer( r, leading ) );
QPixmap pm;
if ( zoom == 1 ) {
pm.convertFromImage( img );
@@ -261,7 +322,7 @@
p.setPen( black );
p.setBrush( white );
p.drawPixmap( int(r.x()*zoom), int(r.y()*zoom), pm,
- int(r.x()*zoom), 0, pm.width(), pm.height() );
+ int(leading*zoom), 0, pm.width(), pm.height() );
} else {
unlock();
}
diff -u /home/mjones/test/qt-2.2.2/tools/qvfb/qvfbview.h ./qvfbview.h
--- /home/mjones/test/qt-2.2.2/tools/qvfb/qvfbview.h Mon Aug 28 21:51:45 2000
+++ ./qvfbview.h Mon Dec 4 10:16:09 2000
@@ -49,6 +54,7 @@
void initLock();
void lock();
void unlock();
+ QImage getBuffer( const QRect &r, int &leading );
void drawScreen();
void sendMouseData( const QPoint &pos, int buttons );
void sendKeyboardData( int unicode, int keycode, int modifiers,
--
[ signature omitted ]
Message 4 in thread
Hello Qt'ers,
I think someone will know the answer to this, because I'm sure I've seen it
in a thread before. But I haven't been able to track it down via searches
in the list archive.
I'll try to simplify the problem, since there's too much code behind it for
anyone to want to look at it. If necessary, I can break it down to a
smaller chunk of code that will (hopefully) still manifest the problem.
I have a series of widgets (derived from QLabels), one of which represents a
trash receptacle. Each of the widgets implements drag and drag and drop
functionality. For the purposes of this discussion, let's just say that you
drag any of the other widgets onto the trash can widget to request its
deletion.
Initiating the drag of a widget creates a drag object. Dropping that drag
object onto the trash can widget emits a signal to top-level UI code. A
slot in the UI code then attempts to delete the designated widget. However,
the app crashes, because the drag object associated with the now deleted
widget manages to generate another event (namely a drag leave event).
My understanding from the documentation is that the drag object should
seamlessly delete itself if its parent object is deleted, but this is not
the case. I seem to recall the aforementioned thread suggesting that the
requested deletion should be deferred via yet another signal and slot, but
I'm not sure exactly what was meant by that.
Thanks for any help or assistance you may be able to provide,
Lance Groody
lance@phototablet.com
Message 5 in thread
Hi Lance,
> I think someone will know the answer to this, because I'm sure I've seen
it
> in a thread before. But I haven't been able to track it down via searches
> in the list archive.
>
> I'll try to simplify the problem, since there's too much code behind it
for
> anyone to want to look at it. If necessary, I can break it down to a
> smaller chunk of code that will (hopefully) still manifest the problem.
>
> I have a series of widgets (derived from QLabels), one of which represents
a
> trash receptacle. Each of the widgets implements drag and drag and drop
> functionality. For the purposes of this discussion, let's just say that
you
> drag any of the other widgets onto the trash can widget to request its
> deletion.
>
> Initiating the drag of a widget creates a drag object. Dropping that drag
> object onto the trash can widget emits a signal to top-level UI code. A
> slot in the UI code then attempts to delete the designated widget.
However,
> the app crashes, because the drag object associated with the now deleted
> widget manages to generate another event (namely a drag leave event).
>
> My understanding from the documentation is that the drag object should
> seamlessly delete itself if its parent object is deleted, but this is not
> the case. I seem to recall the aforementioned thread suggesting that the
> requested deletion should be deferred via yet another signal and slot, but
> I'm not sure exactly what was meant by that.
>
> Thanks for any help or assistance you may be able to provide,
There shouldn't be any problems with deleting the widget in the QDropEvent,
as it will not send out the QDragLeaveEvent event as it has sent out a
QDropEvent event, so the problem sounds like it could be in your code. Can
you send some code that will reproduce the problem, so that I can look into
furthur?
Have a nice day!
Andy
----------------------------------------------------------------------------
---------
andy@trolltech.com Fax: +47 21604801
Trolltech AS, Waldemar Thranes gt. 98B, N-0175 Oslo, Norway
