Re: [Interest] Qt5 mingw builds
One month ago I cross-compiled Qt5 from git sources with mingw ( http://mxe.cc ). It took some magic to compile it. I used this script extracts sources from tar archive, builds and installs. http://pastebin.com/ewDE61GZ But I couldn't compile Qt5 with WebKit support... ( Вторник, 8 января 2013, 23:26 +02:00 от Nikos Chantziaras rea...@gmail.com: On 08/01/13 23:22, Konrad Rosenbaum wrote: On Tuesday 08 January 2013, Diego Iastrubni wrote: So... cross compiling Qt5/win32 from Linux is not possible yet? In theory it should be possible to create a mkspec for this, but nobody attempted it yet. I myself gave up cross-compiling with MinGW from Linux somewhen early in the 4.x run, when my orginal recipe failed. You have to test the software on Windows anyways, so why bother with compiling on a different system? (If it is Bash-Scripts: there is MSys.) It's been working fine for me for ages now, and out of the box with this: http://mxe.cc ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt5 mingw builds
Вторник, 8 января 2013, 23:26 +02:00 от Nikos Chantziaras rea...@gmail.com: On 08/01/13 23:22, Konrad Rosenbaum wrote: On Tuesday 08 January 2013, Diego Iastrubni wrote: So... cross compiling Qt5/win32 from Linux is not possible yet? In theory it should be possible to create a mkspec for this, but nobody attempted it yet. I myself gave up cross-compiling with MinGW from Linux somewhen early in the 4.x run, when my orginal recipe failed. You have to test the software on Windows anyways, so why bother with compiling on a different system? (If it is Bash-Scripts: there is MSys.) It's been working fine for me for ages now, and out of the box with this: http://mxe.cc Дмитрий Козлов wrote: One month ago I cross-compiled Qt5 from git sources with mingw (http://mxe.cc). It took some magic to compile it. I used this script extracts sources from tar archive, builds and installs. http://pastebin.com/ewDE61GZ But I couldn't compile Qt5 with WebKit support... ( No magic is required. The development version (master branch) of MXE already has Qt 5.0.0 in modular form. Use make qtbase to build qtbase, for example. Use make JOBS=4 qtbase to buld it faster on a multicore system. It seems to be working pretty well, although you might have to fix paths in .prl files due to an upstream problems. It's true that webkit is excluded for upstream reasons. For one thing, it doesn't work with static linking. Also, as I understand there is also an upstream problem building webkit on MinGW. By the way, cross building no longer requires a separate mkspec. This is new in Qt 5. Mark ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Where do I find more info about calender system?
On Monday 07 Jan 2013 23:59:45 Soroush Rabiei wrote: Hi I'm interested in QCalenderSystem and its related concepts. I'm planning to implement a third-party lib for Qt5 for Jalali calender. If possible, I would like to integrate it to mainline Qt. Only information I could find is this link: http://qt-project.org/wiki/Qt-5-ICU Just cant wait to get involved! Have some questions about Qt ICU integration to get started working on. 1. What is current progress of calender systems? An implementation or a plan? 2. Is Qt5 supposed to support various calender systems in future releases? Specially I'm interested in Jalali Calender that is official in my country. 3. Is calender systems supposed to be localized and integrated to Qt widgets? 3. Where do I get more info about ? Thanks in advance Hi, The plan is to include ICU support in Qt 5.1, which I am currently working on, and this will implicitly include ICU's support for alternative calendar systems. It is intended that it will be completely seamless within the existing QLocale and QDateTime classes and hence the existing widgets, i.e. if the default system calendar is Jalali then all the widgets will pick up Jalali with no modifications required. Extra api will be added to allow specifically setting the Calendar System on a widget as well. At the moment there's not a lot more detail than what's on the wiki, and an initial code branch on Gitorious, but I'll have more solid details by the end of January as feature-freeze for 5.1 will be in February. Cheers! John. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Crazy Idea of the day: WebGL renderer
You bring up a good point. Maybe the output is JS to the web browser. And I think that is a more awesome solution - because then your deployment platform does not need to support Qt. While I originally conceived of this to introduce people to QML I ran into another idea. I have a Samsung SmartTV which has a HTML5/Webkit app development environment. If Samsung supported WebGL (which they might, I haven't checked) we could write apps for Samsung TV but run them off a remote server. The code on the server would be QML, and we could target any WebGL compliant platform. I don't think performance is that critical. If it was they wouldn't be running it in a browser. ;-) The problem with NaCL is you have to wait and download the entire binary. Meanwhile if you just spit out JS/WebGL commands there is no transfer time. From: Samuel Rødal samuel.ro...@digia.com To: interest@qt-project.org Sent: Wednesday, January 9, 2013 2:21 AM Subject: Re: [Interest] Crazy Idea of the day: WebGL renderer On 01/08/2013 07:35 PM, Jason H wrote: There has been an alarming increase in the number of on-line interactive coding platforms. Take for instance ScraperWiki.com, http://www.typescriptlang.org/Playground/ and a dozen others. While I am waiting for my Qt5 build to download, I was wondering how it would be possible to enable QML in the browser. Chrome how has preliminary WebGL support ( http://www.chromeexperiments.com/webgl/ ) And I figure it would be a hoot and good for Qt5's visibility if we could get an online QML viewer going. Something with and edit pane and a visualization pane. I was thinking QPA might be ideal for this. Do you think it is possible? And how hard would it be? I think such a solution (QPA) might be sub-par (the actual code would have to run on a server, and performance would suffer since you lose the possibility of doing a scene-graph approach with WebGL) to actually parsing and rendering QML with WebGL client-side in the browser, or possibly having a pre-processing step that compiles QML to JavaScript / WebGL. The performance will probably not be as good as a Google Native Client build of Qt though. -- Samuel ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Crazy Idea of the day: WebGL renderer
I just checked the 2013 release of the Samsung SDK supports/will support WebGL. From: Jason H scorp...@yahoo.com To: Samuel Rødal samuel.ro...@digia.com; interest@qt-project.org interest@qt-project.org Sent: Wednesday, January 9, 2013 10:17 AM Subject: Re: [Interest] Crazy Idea of the day: WebGL renderer You bring up a good point. Maybe the output is JS to the web browser. And I think that is a more awesome solution - because then your deployment platform does not need to support Qt. While I originally conceived of this to introduce people to QML I ran into another idea. I have a Samsung SmartTV which has a HTML5/Webkit app development environment. If Samsung supported WebGL (which they might, I haven't checked) we could write apps for Samsung TV but run them off a remote server. The code on the server would be QML, and we could target any WebGL compliant platform. I don't think performance is that critical. If it was they wouldn't be running it in a browser. ;-) The problem with NaCL is you have to wait and download the entire binary. Meanwhile if you just spit out JS/WebGL commands there is no transfer time. From: Samuel Rødal samuel.ro...@digia.com To: interest@qt-project.org Sent: Wednesday, January 9, 2013 2:21 AM Subject: Re: [Interest] Crazy Idea of the day: WebGL renderer On 01/08/2013 07:35 PM, Jason H wrote: There has been an alarming increase in the number of on-line interactive coding platforms. Take for instance ScraperWiki.com, http://www.typescriptlang.org/Playground/ and a dozen others. While I am waiting for my Qt5 build to download, I was wondering how it would be possible to enable QML in the browser. Chrome how has preliminary WebGL support ( http://www.chromeexperiments.com/webgl/ ) And I figure it would be a hoot and good for Qt5's visibility if we could get an online QML viewer going. Something with and edit pane and a visualization pane. I was thinking QPA might be ideal for this. Do you think it is possible? And how hard would it be? I think such a solution (QPA) might be sub-par (the actual code would have to run on a server, and performance would suffer since you lose the possibility of doing a scene-graph approach with WebGL) to actually parsing and rendering QML with WebGL client-side in the browser, or possibly having a pre-processing step that compiles QML to JavaScript / WebGL. The performance will probably not be as good as a Google Native Client build of Qt though. -- Samuel ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Crazy Idea of the day: WebGL renderer
On 01/09/2013 04:17 PM, Jason H wrote: You bring up a good point. Maybe the output is JS to the web browser. And I think that is a more awesome solution - because then your deployment platform does not need to support Qt. While I originally conceived of this to introduce people to QML I ran into another idea. I have a Samsung SmartTV which has a HTML5/Webkit app development environment. If Samsung supported WebGL (which they might, I haven't checked) we could write apps for Samsung TV but run them off a remote server. The code on the server would be QML, and we could target any WebGL compliant platform. I don't think performance is that critical. If it was they wouldn't be running it in a browser. ;-) The problem with NaCL is you have to wait and download the entire binary. Meanwhile if you just spit out JS/WebGL commands there is no transfer time. Well, streaming of JS/WebGL still sounds a bit dubious. Do you force the browser to reevaluate a bunch of JS for each frame? If it's at the QPA level you either need to make a paint engine that generates JS (meaning QML 2 and the scene graph is out), or you have to hook in with a OpenGL library that proxies GL rendering commands (and texture uploads etc) into JS/WebGL. Both but especially the latter would be tons of work. -- Samuel ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Crazy Idea of the day: WebGL renderer
This QML 2 is sounding like it is more a bother than it is worth. I thought QPA was the end-all-be-all of platform abstraction? Why can't QPA be used with scene graph? From: Samuel Rødal samuel.ro...@digia.com To: Jason H scorp...@yahoo.com Cc: interest@qt-project.org interest@qt-project.org Sent: Wednesday, January 9, 2013 10:58 AM Subject: Re: [Interest] Crazy Idea of the day: WebGL renderer On 01/09/2013 04:17 PM, Jason H wrote: You bring up a good point. Maybe the output is JS to the web browser. And I think that is a more awesome solution - because then your deployment platform does not need to support Qt. While I originally conceived of this to introduce people to QML I ran into another idea. I have a Samsung SmartTV which has a HTML5/Webkit app development environment. If Samsung supported WebGL (which they might, I haven't checked) we could write apps for Samsung TV but run them off a remote server. The code on the server would be QML, and we could target any WebGL compliant platform. I don't think performance is that critical. If it was they wouldn't be running it in a browser. ;-) The problem with NaCL is you have to wait and download the entire binary. Meanwhile if you just spit out JS/WebGL commands there is no transfer time. Well, streaming of JS/WebGL still sounds a bit dubious. Do you force the browser to reevaluate a bunch of JS for each frame? If it's at the QPA level you either need to make a paint engine that generates JS (meaning QML 2 and the scene graph is out), or you have to hook in with a OpenGL library that proxies GL rendering commands (and texture uploads etc) into JS/WebGL. Both but especially the latter would be tons of work. -- Samuel___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt5 mingw builds
Hi, On Wednesday 09 January 2013 10:09:13 Дмитрий Козлов wrote: One month ago I cross-compiled Qt5 from git sources with mingw ( http://mxe.cc ). It took some magic to compile it. I used this script extracts sources from tar archive, builds and installs. http://pastebin.com/ewDE61GZ Wow! I wouldn't have expected this! Seems it is time for me to try again. But I couldn't compile Qt5 with WebKit support... ( This matches the situation on native Windows - Webkit does not work for MinGW in Qt 5.0.0. Konrad signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Where do I find more info about calender system?
On Wed, Jan 9, 2013 at 6:32 PM, John Layt jl...@kde.org wrote: Hi, The plan is to include ICU support in Qt 5.1, which I am currently working on, and this will implicitly include ICU's support for alternative calendar systems. It is intended that it will be completely seamless within the existing QLocale and QDateTime classes and hence the existing widgets, i.e. if the default system calendar is Jalali then all the widgets will pick up Jalali with no modifications required. Extra api will be added to allow specifically setting the Calendar System on a widget as well. At the moment there's not a lot more detail than what's on the wiki, and an initial code branch on Gitorious, but I'll have more solid details by the end of January as feature-freeze for 5.1 will be in February. Cheers! John. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest Hi John Great! I would like to contribute to implementation and documenting it. Thanks. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] [PATCH qtbase] qlinuxfbscreen: fix crash in switchToGraphicsMode()
The switchToGraphicsMode() function calls the KDGETMODE ioctl() call,
but passes the address of oldMode, which is already a
pointer. Therefore, the current code makes the kernel write the mode
value returned by the KDGETMODE ioctl() at the address of the oldMode
pointer. This pointer becomes NULL, which makes the following line
trigger a segfault.
Since the function already receives as argument the address of
oldMode, there is no need to do oldMode when doing the ioctl() call.
This patch fixes the following segfault:
Program received signal SIGSEGV, Segmentation fault.
0x768acc40 in switchToGraphicsMode (oldMode=0x0, ttyfd=7) at
qlinuxfbscreen.cpp:268
268if (*oldMode != KD_GRAPHICS) {
(gdb) bt
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
src/plugins/platforms/linuxfb/qlinuxfbscreen.cpp |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/plugins/platforms/linuxfb/qlinuxfbscreen.cpp
b/src/plugins/platforms/linuxfb/qlinuxfbscreen.cpp
index 1dac60a..4d170f1 100644
--- a/src/plugins/platforms/linuxfb/qlinuxfbscreen.cpp
+++ b/src/plugins/platforms/linuxfb/qlinuxfbscreen.cpp
@@ -264,7 +264,7 @@ static int openTtyDevice(const QString device)
static bool switchToGraphicsMode(int ttyfd, int *oldMode)
{
-ioctl(ttyfd, KDGETMODE, oldMode);
+ioctl(ttyfd, KDGETMODE, oldMode);
if (*oldMode != KD_GRAPHICS) {
if (ioctl(ttyfd, KDSETMODE, KD_GRAPHICS) != 0)
return false;
--
1.7.9.5
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Crash when starting Qt5 rasterwindow on ARM/linuxfb
Hello, I am currently packaging Qt5 for the Buildroot embedded Linux build system (http://buildroot.org). I am therefore trying to get the 'rasterwindow' example (from qtbase/examples/gui/rasterwindow/) to run with the 'linuxfb' graphics backend on a ARM platform (currently a Cortex-A8 platform emulated by Qemu). I first got a segfault that I could fix, see the patch '[PATCH qtbase] qlinuxfbscreen: fix crash in switchToGraphicsMode()' I just send to this list. But once this first easy issue was fixed, I got another segfault, which this time requires more knowledge of Qt internals, which I don't have. So, basically, I'm starting my application as follows: ./rasterwindow -platform linuxfb and I get the following trace in gdb: Program received signal SIGSEGV, Segmentation fault. QFbBackingStore::QFbBackingStore (this=0x17588, window=0x7efffc34) at fbconvenience/qfbbackingstore.cpp:54 54 (static_castQFbWindow *(window-handle()))-setBackingStore(this); (gdb) bt #0 QFbBackingStore::QFbBackingStore (this=0x17588, window=0x7efffc34) at fbconvenience/qfbbackingstore.cpp:54 #1 0x768ac016 in QLinuxFbIntegration::createPlatformBackingStore (this=optimized out, window=0x7efffc34) at qlinuxfbintegration.cpp:87 #2 0x76f33438 in QBackingStore::QBackingStore (this=0x19008, window=0x7efffc34) at painting/qbackingstore.cpp:122 Does anyone has an idea? Should I be doing a formal bug report? Thanks for your help, Thomas Petazzoni -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] [PATCH qtbase] qlinuxfbscreen: fix crash in switchToGraphicsMode()
Hi Thomas, On 9 January 2013 23:32, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: The switchToGraphicsMode() function calls the KDGETMODE ioctl() call, but passes the address of oldMode, which is already a pointer. Therefore, the current code makes the kernel write the mode value returned by the KDGETMODE ioctl() at the address of the oldMode pointer. This pointer becomes NULL, which makes the following line trigger a segfault. Since the function already receives as argument the address of oldMode, there is no need to do oldMode when doing the ioctl() call. This patch fixes the following segfault: Thanks for the fix, but although it's trifial, for legal reasons the Qt Project can't accept patches from the mailing list (or the bugtracker). Please consider spending 5 minutes to set up Gerrit and pushing this fix: http://qt-project.org/wiki/Setting-up-Gerrit Cheers, -- Giuseppe D'Angelo ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Implementing custom orientation sensor using QtSensors
On 10/01/13 07:23, Jim Hodapp wrote:
I'm attempting to create my own orientation sensor that sits on top of a
particular accelerometer implementation. I'd like to use my orientation
sensor from a QML application. Given what I just stated, I'm looking for
the recommended approach to implementing my own orientation sensor and
using it in QML. Let me explain further with the following questions:
1. Do I want to create a new class, call it MyOrientationSensor, that
inherits from QOrientationSensor and a paired class for the reading,
call it MyOrientationReading? Or do I want to implement it like the
GrueSensor example and inherit from QSensor?
Neither.
You should create a class that provides accelerometer values to
QAccelerometer (a sub-class of QSensorBackend).
Or, if there's some reason why the generic accelerometer to
orientation implementation does not suit your purposes, create a class
that provides orientation values to QOrientationSensor.
2. If taking the GrueSensor approach from #1, how do I avoid
reimplementing the interface and implementation of the
QOrientationSensor again?
You can't avoid this if you're going to copy the interface. So don't do
that.
3. Next, using my sensor within QML, if taking the GrueSensor approach,
I know I'd then import my own QML package and instantiate my sensor by
its unique name. But if the approach is the use the same name as the
default orientation sensor type, i.e. OrientationSensor, how do I make
sure that it selects my orientation sensor as the one to use and not one
of the sensors from dummy sensors, generic sensors, etc? Do I need to
register another type with QML, or does it automatically get registered
using this approach?
The grue sensor example is a complete example, creating both a front
end and a back end. In your case, you're just creating a back end,
which includes the plugin that registers your backend with the Qt
Sensors API.
http://llornkcor.com/qt/doc/qtsensors/creating-a-sensor-plugin.html
Your backend will always override the generic one due to some logic in
the loader. Otherwise, the default is up to the platform and can be
influenced in a number of ways.
http://llornkcor.com/qt/doc/qtsensors/determining-the-default-sensor-for-a-type.html
From QML, I think you can do:
OrientationSensor {
sensorid: my.sensor
}
Though this ties your QML to your plugin. If you want to do any kind of
detection, you need to create the object dynamically.
--
Link
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Mixin Tree View Table view
What Im trying to do... I would like a root tree node, with a set of child tree item nodes. Under each tree item, I would like to show a table.. The data model, imagine SQL query grouped by a particular text item.. The text item, would represent the child tree items. The other table columns would be the table. One table per tree item. Any thoughts/ideas on how to implement this? Scott ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5 and filesystem
Even though this thread is about QML, I stumbled upon this question while reading (and noting that iOS doesn't provide a system file dialog component): What happens when you try to use QFileDialog (widget) in iOS Qt? I don't own any Apple products so can't test it. This spurs yet another question: Will Widgets even be supported on the mobile QPA targets? All the attention goes to QML these days, but there would need to be work done in order for the Widgets are still supported claim to remain true. Done comes to mind. As for file dialogs in particular, it sounds like Qt needs to provide it's own for systems that don't support it. Would that generic file dialog be dependent on QML or on Widgets? We'd need both versions in order to not make one dependent on the other. insert generic quip about QML splitting the development resources. Lastly, a decent compromise between Tree View and Bread Crumbs would be drag-n-drop enabled breadcrumbs, where hovering over the breadcrumb while holding down the mouse during a drag-n-drop changes to the folder for dropping into. Xfce's file manager does this, though it does copy/paste instead of cut/paste. d3fault ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Crazy Idea of the day: WebGL renderer
On 01/09/2013 05:15 PM, Jason H wrote: This QML 2 is sounding like it is more a bother than it is worth. I thought QPA was the end-all-be-all of platform abstraction? Why can't QPA be used with scene graph? Of course it can, it's just that scene graph uses OpenGL ES 2 and not QPainter, so if you want to change how the scene graph rendering is finally done you need to hook in at the OpenGL library level (or with a proxying library), similar to how ANGLE is used on Windows to proxy OpenGL commands into Direct3D. Well, outside of QPA / OpenGL scene graph also has its own adaptation layer where you can make a custom renderer, so maybe that would be a better place to do this kind of thing. -- Samuel ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Crash when starting Qt5 rasterwindow on ARM/linuxfb
On 01/09/2013 11:36 PM, Thomas Petazzoni wrote: Hello, I am currently packaging Qt5 for the Buildroot embedded Linux build system (http://buildroot.org). I am therefore trying to get the 'rasterwindow' example (from qtbase/examples/gui/rasterwindow/) to run with the 'linuxfb' graphics backend on a ARM platform (currently a Cortex-A8 platform emulated by Qemu). I first got a segfault that I could fix, see the patch '[PATCH qtbase] qlinuxfbscreen: fix crash in switchToGraphicsMode()' I just send to this list. But once this first easy issue was fixed, I got another segfault, which this time requires more knowledge of Qt internals, which I don't have. So, basically, I'm starting my application as follows: ./rasterwindow -platform linuxfb and I get the following trace in gdb: Program received signal SIGSEGV, Segmentation fault. QFbBackingStore::QFbBackingStore (this=0x17588, window=0x7efffc34) at fbconvenience/qfbbackingstore.cpp:54 54(static_castQFbWindow *(window-handle()))-setBackingStore(this); (gdb) bt #0 QFbBackingStore::QFbBackingStore (this=0x17588, window=0x7efffc34) at fbconvenience/qfbbackingstore.cpp:54 #1 0x768ac016 in QLinuxFbIntegration::createPlatformBackingStore (this=optimized out, window=0x7efffc34) at qlinuxfbintegration.cpp:87 #2 0x76f33438 in QBackingStore::QBackingStore (this=0x19008, window=0x7efffc34) at painting/qbackingstore.cpp:122 Does anyone has an idea? Should I be doing a formal bug report? Seems like a bug in the qlinuxfb platform. QFbBackingStore is assuming that create() has already been called on the QWindow. Before create() is called window-handle() will return 0. It's probably better if QFbBackingStore does this initialization lazily. -- Samuel ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] [PATCH qtbase] qlinuxfbscreen: fix crash in switchToGraphicsMode()
Hi, On Wednesday 09 January 2013 23:48:42 Giuseppe D'Angelo wrote: On 9 January 2013 23:32, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: The switchToGraphicsMode() function calls the KDGETMODE ioctl() call, but passes the address of oldMode, which is already a pointer. Therefore, the current code makes the kernel write the mode value returned by the KDGETMODE ioctl() at the address of the oldMode pointer. This pointer becomes NULL, which makes the following line trigger a segfault. Since the function already receives as argument the address of oldMode, there is no need to do oldMode when doing the ioctl() call. This patch fixes the following segfault: Thanks for the fix, but although it's trifial, for legal reasons the Qt Project can't accept patches from the mailing list (or the bugtracker). Please consider spending 5 minutes to set up Gerrit and pushing this fix: How about reviewing and accepting one from someone who already accepted the Agreement: https://codereview.qt-project.org/#change,39400 It's identical to Thomas' code. Konrad signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
