GSoC proposal: Quirinus C library (qc)
Hello everyone! My name is Dmitry, I'm 22 years old student from Lomonosov Moscow State University of Russia. This message is addressed mainly to C connoiseurs, yet I think other people may find it interesting. It's a GSoC proposal. First I've sent it to FreeBSD only since I didn't know that OpenBSD is accepted into GSoC too, so the rest is a copy of the original letter to FreeBSD mailing list with small changes. It's a pity that for language like C we generally don't have something universal like Boost, so we have to implement some common functions from scratch or introduce new dependencies. We have Glib, which is used mainly by Gnome developers (though it is a standalone library) and LGPL-ed, which is not as liberal as Boost's license. We also have APR, which seems to be a bit more comprehensive and convenient, yet it is not so well-known as Glib. I'm in process of implementing a something like Boost for ANSI C (though I don't pretend this library to share Boost's comprehensiveness). Several ideas I find useful are: 1. Strict and universal interface. Each function begins with qc_ prefix, followed by type if function is type-related. Most of types (except enum-typedef'ed ones) have three common functions (replace _type_ with the necessary type name, e.g. _bytes_): a. Constructor: void * qc_type_construct(void). Allocate object instance and initialize it to default value. b. Destructor: void qc_type_destruct(void * pointer). Deallocate memory allocated for object and its members. c. Replicator: void * qc_type_replicate(void const * pointer). Replicate object, copying its data to new allocated object, i.e. clone. Most of types also have _import_ and _export_ functions, which allow to fill allocated object with the desired data (e.g. fill bytes instance from null-terminated char string) or export data to another type. Almost all enum-typedef'ed types also have _import_ and _export_ functions to retrieve a key value corresponding to string. 2. Common and universal error type, qc_error. Such errors can be generated from errno values as well as from Windows API errors. Almost all functions from qc library except for the three common functions (constructor, destructor, replicator) return qc_error code and set specific qc_errno variable to this code. It is now possible to write such constructions: if (qc_bytes_import_str(bytes_instance, Hello, world!)) qc_errormsg(qc_errno, error check); Global variable qc_errno is implemented in terms of multithreading applications, it is unique for every running thread. 3. Clear distinction between byte and Unicode strings (qc_byte and qc_ucs types for characters, where qc_byte has exactly 8-bit width and qc_ucs has exactly 32-bit width). Charsets are just enumeration, e.g. QC_ENCODING_UTF8, QC_ENCODING_ISO_8859_4, etc., yet it is possible to lookup the desired encoding using qc_encoding_import. If encoding is known under several names, they are handled alltogether, i.e. QC_ENCODING_ASCII will be returned for any of ASCII, iso-ir-6, ANSI_X3.4-1968, ISO646-US, etc. Register doesn't matter. Two new types, qc_bytes and qc_unicode are provided, in order to store binary and Unicode data. It is possible to store null characters inside such objects. It is similar to C++ string and C++ vector classes. 4. Universal file system path type. It is possible to achieve cross-platformness using such path types, i.e. it is possible to make directories, links, symlinks, remove files, directories, etc. regardless of platform path API. 5. i18n support must be embedded with qc library. Locales, timezones, day and months names, etc. must be provided too, in several forms if necessary. i18n functions work with qc_unicode type, so charset conversion problems won't exist. 6. Multithreading support if platform permits it. On POSIX we use pthreads, on Windows we use its API for multithreading. I'm also thinking about green threads implementation. Thread local storage is already implemented, yet there is still a lot work to be done with threads, mutexes, etc. 7. Multiprecision arithmetics. I'm using GMP to achieve it, yet I'm planning to switch to something BSD-like or to implement it from scratch (that probably would be better, since library doesn't introduce any dependencies except GMP). 8. Ternary logic almost everywhere. Being fan of Russian Setun computer, I've started this library as implementation of ternary logic operations. When I've realized that there is still much to be done in other fields, I've already concluded that ternary logic is suitable for a wide set of other operations, e.g. comparison, determining type of strings, endianness, etc. I think that I'll leave type qc_trit, since I've found it extremely useful. 9. A lot of other things to be done, such as unified I/O streams which provide compression/transformation filters, protocols, math library, etc. Why am I writing such letter to BSD world? I'm pretty sure that every BSD system highly needs such library,
Re: azalia(4): RIRB DMA engine needs delay after started
Date: Tue, 25 Feb 2014 06:05:02 +0900
From: SASANO Takayoshi u...@mx5.nisiq.net
Hello,
I am trying OpenBSD-current/i386 on 86duino EduCake.
It uses DMP Vortex86EX SoC and its azalia fails to find ALC262 codec.
The diagnostic message says RIRB is not running
(at azalia_get_response()), and I found Vortex86EX's azalia takes 2~4
DELAY(1)s to start RIRB DMA engine.
(Vortex86EX's CORB DMA did not required any delay. It starts immediately.)
Here is the patch to add delay.
Thanks, here is a slightly reworked diff that does the wait in a way
that's more in line with other bits of azalia(4) that wait for a bit
in a register to go on or off.
Index: azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.209
diff -u -p -r1.209 azalia.c
--- azalia.c30 Dec 2013 10:53:30 - 1.209
+++ azalia.c25 Feb 2014 16:06:22 -
@@ -1110,7 +1110,7 @@ azalia_halt_rirb(azalia_t *az)
int
azalia_init_rirb(azalia_t *az, int resuming)
{
- int err;
+ int err, i;
uint16_t rirbwp;
uint8_t rirbctl;
@@ -1161,6 +1161,16 @@ azalia_init_rirb(azalia_t *az, int resum
rirbctl = AZ_READ_1(az, RIRBCTL);
AZ_WRITE_1(az, RIRBCTL, rirbctl |
HDA_RIRBCTL_RIRBDMAEN | HDA_RIRBCTL_RINTCTL);
+ for (i = 5000; i = 0; i--) {
+ DELAY(10);
+ rirbctl = AZ_READ_1(az, RIRBCTL);
+ if (rirbctl HDA_RIRBCTL_RIRBDMAEN)
+ break;
+ }
+ if (i = 0) {
+ DPRINTF((%s: RIRB is not running\n, XNAME(az)));
+ return(EBUSY);
+ }
return (0);
}
Re: GSoC proposal: Quirinus C library (qc)
On 25 February 2014 11:39, Dmitry Selyutin ghostman...@gmail.com wrote: It's a pity that for language like C we generally don't have something universal like Boost, so we have to implement some common functions from scratch or introduce new dependencies. We have Glib, which is used mainly by Gnome developers (though it is a standalone library) and LGPL-ed, which is not as liberal as Boost's license. We also have APR, which seems to be a bit more comprehensive and convenient, yet it is not so well-known as Glib. I'm in process of implementing a something like Boost for ANSI C (though I don't pretend this library to share Boost's comprehensiveness). Several ideas I find useful are: Well, what you'll find here in OpenBSD is that a lot of projects---and by that I mean those Open* ones affiliated with OpenBSD, or those maintained as part of src/ (core) to have some convention like xfoo() where foo() is some standard library which has been wrapped to provide additional checking/functionality. A good example of this is xmalloc() which tends to check the return value from malloc() as not NULL and acting accordingly. Are you saying your Quirinus library should help reduce this duplication? In terms of things like data structures, we have TAILQ, CIRCLEQ, and RB_TREES all of which are surprisingly not portable without the header files outside of BSD. Additionally, OpenBSD has things like strtonum(), strlcpy(), etc., all of which provide solutions to specific problems. How does your proposed library help unify these, seeing as they already exist? 1. Strict and universal interface. Each function begins with qc_ prefix, That's more a naming convention than an interface. followed by type if function is type-related. Most of types (except enum-typedef'ed ones) have three common functions (replace _type_ with the necessary type name, e.g. _bytes_): a. Constructor: void * qc_type_construct(void). Allocate object instance and initialize it to default value. b. Destructor: void qc_type_destruct(void * pointer). Deallocate memory allocated for object and its members. c. Replicator: void * qc_type_replicate(void const * pointer). Replicate object, copying its data to new allocated object, i.e. clone. Hmm. I am not sure I like this---but my immediate question is why is this better than what we have now, and where might you consider its replacement within OpenBSD to be beneficial? Do you have an example? 2. Common and universal error type, qc_error. Such errors can be generated from errno values as well as from Windows API errors. Welcome to strerrno() [...] -- Thomas Adam
Re: azalia(4): RIRB DMA engine needs delay after started
Tangent:
I don't like the style used for the delay loops in azalia.c.
1. There's an off by one where 0 passes both conditionals. It's
unlikely this matters, but it's needless inconsistency.
2. I think i = 0 is a dangerous idiom because any code refactor that
changes the variable in question to unsigned introduces an infinite
loop.
This can wait til after 5.5, but I made the diff since I was looking
at the code.
Index: azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.210
diff -u -p -r1.210 azalia.c
--- azalia.c25 Feb 2014 18:40:37 - 1.210
+++ azalia.c25 Feb 2014 20:02:20 -
@@ -771,26 +771,26 @@ azalia_reset(azalia_t *az)
DPRINTF((%s: resetting\n, __func__));
gctl = AZ_READ_4(az, GCTL);
AZ_WRITE_4(az, GCTL, gctl ~HDA_GCTL_CRST);
- for (i = 5000; i = 0; i--) {
+ for (i = 5000; i 0; i--) {
DELAY(10);
if ((AZ_READ_4(az, GCTL) HDA_GCTL_CRST) == 0)
break;
}
DPRINTF((%s: reset counter = %d\n, __func__, i));
- if (i = 0) {
+ if (i == 0) {
DPRINTF((%s: reset failure\n, XNAME(az)));
return(ETIMEDOUT);
}
DELAY(1000);
gctl = AZ_READ_4(az, GCTL);
AZ_WRITE_4(az, GCTL, gctl | HDA_GCTL_CRST);
- for (i = 5000; i = 0; i--) {
+ for (i = 5000; i 0; i--) {
DELAY(10);
if (AZ_READ_4(az, GCTL) HDA_GCTL_CRST)
break;
}
DPRINTF((%s: reset counter = %d\n, __func__, i));
- if (i = 0) {
+ if (i == 0) {
DPRINTF((%s: reset-exit failure\n, XNAME(az)));
return(ETIMEDOUT);
}
@@ -1016,13 +1016,13 @@ azalia_halt_corb(azalia_t *az)
corbctl = AZ_READ_1(az, CORBCTL);
if (corbctl HDA_CORBCTL_CORBRUN) { /* running? */
AZ_WRITE_1(az, CORBCTL, corbctl ~HDA_CORBCTL_CORBRUN);
- for (i = 5000; i = 0; i--) {
+ for (i = 5000; i 0; i--) {
DELAY(10);
corbctl = AZ_READ_1(az, CORBCTL);
if ((corbctl HDA_CORBCTL_CORBRUN) == 0)
break;
}
- if (i = 0) {
+ if (i == 0) {
DPRINTF((%s: CORB is running\n, XNAME(az)));
return EBUSY;
}
@@ -1061,13 +1061,13 @@ azalia_init_corb(azalia_t *az, int resum
corbrp = AZ_READ_2(az, CORBRP);
AZ_WRITE_2(az, CORBRP, corbrp | HDA_CORBRP_CORBRPRST);
AZ_WRITE_2(az, CORBRP, corbrp ~HDA_CORBRP_CORBRPRST);
- for (i = 5000; i = 0; i--) {
+ for (i = 5000; i 0; i--) {
DELAY(10);
corbrp = AZ_READ_2(az, CORBRP);
if ((corbrp HDA_CORBRP_CORBRPRST) == 0)
break;
}
- if (i = 0) {
+ if (i == 0) {
DPRINTF((%s: CORBRP reset failure\n, XNAME(az)));
return -1;
}
@@ -1093,13 +1093,13 @@ azalia_halt_rirb(azalia_t *az)
rirbctl = AZ_READ_1(az, RIRBCTL);
if (rirbctl HDA_RIRBCTL_RIRBDMAEN) { /* running? */
AZ_WRITE_1(az, RIRBCTL, rirbctl ~HDA_RIRBCTL_RIRBDMAEN);
- for (i = 5000; i = 0; i--) {
+ for (i = 5000; i 0; i--) {
DELAY(10);
rirbctl = AZ_READ_1(az, RIRBCTL);
if ((rirbctl HDA_RIRBCTL_RIRBDMAEN) == 0)
break;
}
- if (i = 0) {
+ if (i == 0) {
DPRINTF((%s: RIRB is running\n, XNAME(az)));
return(EBUSY);
}
@@ -1161,13 +1161,13 @@ azalia_init_rirb(azalia_t *az, int resum
rirbctl = AZ_READ_1(az, RIRBCTL);
AZ_WRITE_1(az, RIRBCTL, rirbctl |
HDA_RIRBCTL_RIRBDMAEN | HDA_RIRBCTL_RINTCTL);
- for (i = 5000; i = 0; i--) {
+ for (i = 5000; i 0; i--) {
DELAY(10);
rirbctl = AZ_READ_1(az, RIRBCTL);
if (rirbctl HDA_RIRBCTL_RIRBDMAEN)
break;
}
- if (i = 0) {
+ if (i == 0) {
DPRINTF((%s: RIRB is not running\n, XNAME(az)));
return(EBUSY);
}
@@ -1244,7 +1244,7 @@ azalia_get_response(azalia_t *az, uint32
DELAY(10);
i--;
}
- if (i = 0) {
+ if (i == 0) {
DPRINTF((%s: RIRB time out\n, XNAME(az)));
return(ETIMEDOUT);
}
@@ -3708,26 +3708,26 @@ azalia_stream_reset(stream_t *this)
/* Start reset and wait for chip to enter. */
ctl = STR_READ_2(this, CTL);
STR_WRITE_2(this, CTL, ctl |
Re: azalia(4): RIRB DMA engine needs delay after started
On Tue, Feb 25, 2014 at 15:08, Ted Unangst wrote: Tangent: I don't like the style used for the delay loops in azalia.c. 1. There's an off by one where 0 passes both conditionals. It's unlikely this matters, but it's needless inconsistency. 2. I think i = 0 is a dangerous idiom because any code refactor that changes the variable in question to unsigned introduces an infinite loop. Sorry, stupid typo. I'm concerned about the loop conditional, i = 0.
Re: azalia(4): RIRB DMA engine needs delay after started
Hi, Thanks, here is a slightly reworked diff that does the wait in a way that's more in line with other bits of azalia(4) that wait for a bit in a register to go on or off. Okay, there is no problem with my 86duino EduCake. Thanks. -- SASANO Takayoshi u...@mx5.nisiq.net
Re: azalia(4): RIRB DMA engine needs delay after started
Date: Tue, 25 Feb 2014 15:08:48 -0500
From: Ted Unangst t...@tedunangst.com
Tangent:
I don't like the style used for the delay loops in azalia.c.
1. There's an off by one where 0 passes both conditionals. It's
unlikely this matters, but it's needless inconsistency.
2. I think i = 0 is a dangerous idiom because any code refactor that
changes the variable in question to unsigned introduces an infinite
loop.
This can wait til after 5.5, but I made the diff since I was looking
at the code.
ok kettenis@, but I think you should wait until after release
Index: azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.210
diff -u -p -r1.210 azalia.c
--- azalia.c 25 Feb 2014 18:40:37 - 1.210
+++ azalia.c 25 Feb 2014 20:02:20 -
@@ -771,26 +771,26 @@ azalia_reset(azalia_t *az)
DPRINTF((%s: resetting\n, __func__));
gctl = AZ_READ_4(az, GCTL);
AZ_WRITE_4(az, GCTL, gctl ~HDA_GCTL_CRST);
- for (i = 5000; i = 0; i--) {
+ for (i = 5000; i 0; i--) {
DELAY(10);
if ((AZ_READ_4(az, GCTL) HDA_GCTL_CRST) == 0)
break;
}
DPRINTF((%s: reset counter = %d\n, __func__, i));
- if (i = 0) {
+ if (i == 0) {
DPRINTF((%s: reset failure\n, XNAME(az)));
return(ETIMEDOUT);
}
DELAY(1000);
gctl = AZ_READ_4(az, GCTL);
AZ_WRITE_4(az, GCTL, gctl | HDA_GCTL_CRST);
- for (i = 5000; i = 0; i--) {
+ for (i = 5000; i 0; i--) {
DELAY(10);
if (AZ_READ_4(az, GCTL) HDA_GCTL_CRST)
break;
}
DPRINTF((%s: reset counter = %d\n, __func__, i));
- if (i = 0) {
+ if (i == 0) {
DPRINTF((%s: reset-exit failure\n, XNAME(az)));
return(ETIMEDOUT);
}
@@ -1016,13 +1016,13 @@ azalia_halt_corb(azalia_t *az)
corbctl = AZ_READ_1(az, CORBCTL);
if (corbctl HDA_CORBCTL_CORBRUN) { /* running? */
AZ_WRITE_1(az, CORBCTL, corbctl ~HDA_CORBCTL_CORBRUN);
- for (i = 5000; i = 0; i--) {
+ for (i = 5000; i 0; i--) {
DELAY(10);
corbctl = AZ_READ_1(az, CORBCTL);
if ((corbctl HDA_CORBCTL_CORBRUN) == 0)
break;
}
- if (i = 0) {
+ if (i == 0) {
DPRINTF((%s: CORB is running\n, XNAME(az)));
return EBUSY;
}
@@ -1061,13 +1061,13 @@ azalia_init_corb(azalia_t *az, int resum
corbrp = AZ_READ_2(az, CORBRP);
AZ_WRITE_2(az, CORBRP, corbrp | HDA_CORBRP_CORBRPRST);
AZ_WRITE_2(az, CORBRP, corbrp ~HDA_CORBRP_CORBRPRST);
- for (i = 5000; i = 0; i--) {
+ for (i = 5000; i 0; i--) {
DELAY(10);
corbrp = AZ_READ_2(az, CORBRP);
if ((corbrp HDA_CORBRP_CORBRPRST) == 0)
break;
}
- if (i = 0) {
+ if (i == 0) {
DPRINTF((%s: CORBRP reset failure\n, XNAME(az)));
return -1;
}
@@ -1093,13 +1093,13 @@ azalia_halt_rirb(azalia_t *az)
rirbctl = AZ_READ_1(az, RIRBCTL);
if (rirbctl HDA_RIRBCTL_RIRBDMAEN) { /* running? */
AZ_WRITE_1(az, RIRBCTL, rirbctl ~HDA_RIRBCTL_RIRBDMAEN);
- for (i = 5000; i = 0; i--) {
+ for (i = 5000; i 0; i--) {
DELAY(10);
rirbctl = AZ_READ_1(az, RIRBCTL);
if ((rirbctl HDA_RIRBCTL_RIRBDMAEN) == 0)
break;
}
- if (i = 0) {
+ if (i == 0) {
DPRINTF((%s: RIRB is running\n, XNAME(az)));
return(EBUSY);
}
@@ -1161,13 +1161,13 @@ azalia_init_rirb(azalia_t *az, int resum
rirbctl = AZ_READ_1(az, RIRBCTL);
AZ_WRITE_1(az, RIRBCTL, rirbctl |
HDA_RIRBCTL_RIRBDMAEN | HDA_RIRBCTL_RINTCTL);
- for (i = 5000; i = 0; i--) {
+ for (i = 5000; i 0; i--) {
DELAY(10);
rirbctl = AZ_READ_1(az, RIRBCTL);
if (rirbctl HDA_RIRBCTL_RIRBDMAEN)
break;
}
- if (i = 0) {
+ if (i == 0) {
DPRINTF((%s: RIRB is not running\n, XNAME(az)));
return(EBUSY);
}
@@ -1244,7 +1244,7 @@ azalia_get_response(azalia_t *az, uint32
DELAY(10);
i--;
}
- if (i = 0) {
+ if (i == 0) {
DPRINTF((%s: RIRB time out\n, XNAME(az)));
return(ETIMEDOUT);
}
@@ -3708,26 +3708,26 @@ azalia_stream_reset(stream_t *this)
/* Start reset and wait for chip to enter. */
ctl =
Re: GSoC proposal: Quirinus C library (qc)
On Tue, Feb 25, 2014 at 3:39 PM, Dmitry Selyutin ghostman...@gmail.com wrote: Hello everyone! My name is Dmitry, I'm 22 years old student from Lomonosov Moscow State University of Russia. This message is addressed mainly to C connoiseurs, yet I think other people may find it interesting. It's a GSoC proposal. First I've sent it to FreeBSD only since I didn't know that OpenBSD is accepted into GSoC too, so the rest is a copy of the original letter to FreeBSD mailing list with small changes. Hi Dmitry ! Also, please have a look at the list of projects at http://www.openbsdfoundation.org/gsoc2014.html Since you like hacking on libs, have you considered looking at this project and the SD/MMC stack project : http://www.openbsdfoundation.org/gsoc2014.html#usb-userland-xfer http://www.openbsdfoundation.org/gsoc2014.html#sdmmc It's nice to have a suggestion, but please pay attention to the _current_ problems that OpenBSD developers are interested to solve. (Go through the tech archieves). If you find something that you would like to solve, and it has been discussed quite a few times on tech, I would suggest that you mail the developer and ask for more information :-) Good luck. It's a pity that for language like C we generally don't have something universal like Boost, so we have to implement some common functions from scratch or introduce new dependencies. We have Glib, which is used mainly by Gnome developers (though it is a standalone library) and LGPL-ed, which is not as liberal as Boost's license. We also have APR, which seems to be a bit more comprehensive and convenient, yet it is not so well-known as Glib. I'm in process of implementing a something like Boost for ANSI C (though I don't pretend this library to share Boost's comprehensiveness). Several ideas I find useful are: 1. Strict and universal interface. Each function begins with qc_ prefix, followed by type if function is type-related. Most of types (except enum-typedef'ed ones) have three common functions (replace _type_ with the necessary type name, e.g. _bytes_): a. Constructor: void * qc_type_construct(void). Allocate object instance and initialize it to default value. b. Destructor: void qc_type_destruct(void * pointer). Deallocate memory allocated for object and its members. c. Replicator: void * qc_type_replicate(void const * pointer). Replicate object, copying its data to new allocated object, i.e. clone. Most of types also have _import_ and _export_ functions, which allow to fill allocated object with the desired data (e.g. fill bytes instance from null-terminated char string) or export data to another type. Almost all enum-typedef'ed types also have _import_ and _export_ functions to retrieve a key value corresponding to string. 2. Common and universal error type, qc_error. Such errors can be generated from errno values as well as from Windows API errors. Almost all functions from qc library except for the three common functions (constructor, destructor, replicator) return qc_error code and set specific qc_errno variable to this code. It is now possible to write such constructions: if (qc_bytes_import_str(bytes_instance, Hello, world!)) qc_errormsg(qc_errno, error check); Global variable qc_errno is implemented in terms of multithreading applications, it is unique for every running thread. 3. Clear distinction between byte and Unicode strings (qc_byte and qc_ucs types for characters, where qc_byte has exactly 8-bit width and qc_ucs has exactly 32-bit width). Charsets are just enumeration, e.g. QC_ENCODING_UTF8, QC_ENCODING_ISO_8859_4, etc., yet it is possible to lookup the desired encoding using qc_encoding_import. If encoding is known under several names, they are handled alltogether, i.e. QC_ENCODING_ASCII will be returned for any of ASCII, iso-ir-6, ANSI_X3.4-1968, ISO646-US, etc. Register doesn't matter. Two new types, qc_bytes and qc_unicode are provided, in order to store binary and Unicode data. It is possible to store null characters inside such objects. It is similar to C++ string and C++ vector classes. 4. Universal file system path type. It is possible to achieve cross-platformness using such path types, i.e. it is possible to make directories, links, symlinks, remove files, directories, etc. regardless of platform path API. 5. i18n support must be embedded with qc library. Locales, timezones, day and months names, etc. must be provided too, in several forms if necessary. i18n functions work with qc_unicode type, so charset conversion problems won't exist. 6. Multithreading support if platform permits it. On POSIX we use pthreads, on Windows we use its API for multithreading. I'm also thinking about green threads implementation. Thread local storage is already implemented, yet there is still a lot work to be done with threads, mutexes, etc. 7. Multiprecision arithmetics. I'm using GMP to achieve it, yet I'm planning to switch to
Re: azalia(4): RIRB DMA engine needs delay after started
Hello, This can wait til after 5.5, but I made the diff since I was looking at the code. ok by sasano@, it works on my 86duino EduCake! SASANO Takayoshi u...@mx5.nisiq.net
Re: Intel HD Graphics 4000, only one monitor detected
2014-02-14 15:15 GMT+01:00 Markus Bergkvist mar...@familjenbergkvist.net: Synced and verified that kettenis patch was there but unfortunately it did not help with a new kernel. 2014-02-14 9:54 GMT+01:00 Jonathan Gray j...@jsg.id.au: On Fri, Feb 14, 2014 at 08:48:04AM +0100, Markus Bergkvist wrote: I did an update to recent snapshot OpenBSD 5.5-beta (GENERIC.MP) #287: Fri Feb 7 11:45:09 MST 2014 I have two identical monitors connected to my Intel HD Graphics 4000 on DisplayPort and HDMI respectively. Usually there is no problem detecting them both and split my desktop across both monitors. But somewhere between OpenBSD 5.5-beta (GENERIC.MP) #284: Mon Feb 3 07:57:32 MST 2014 and OpenBSD 5.5-beta (GENERIC.MP) #287: Fri Feb 7 11:45:09 MST 2014 something happened. The monitor on HDMI is mirroring the DisplayPort and it is not detected by xrand. Output from xrandr, diff between previous and current dmesg and a complete dmesg below. Any suggestion on what might be wrong? Any more information I can provide? The xf86-video-intel driver was recently updated, this triggered a bug in copying data out of the kernel that was previously hidden which affects xrandr. It would be interesting to see if compiling your own kernel sometime after the following commit by kettenis@ helps: CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2014/02/13 05:33:08 Modified files: sys/dev/pci/drm: drm_crtc.c Log message: Make sure we copy out the right amount of data in the various copyout() calls that replace the put_user() calls in the Linux code by using sizeof on the appropriate variables instead of explicit uint32_t/uint64_t types. Fixes a case where we accidentally copied out only 32 bits of a 64-bit value, uncovered by xf86-video-intel 2.99.909. ok jsg@, matthieu@ Updated to recent snapshot. Monitor on HDMI-port is detected but is disconnected? $ xrandr Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 32767 x 32767 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected 1920x1200+0+0 (normal left inverted right x axis y axis) 0mm x 0mm HDMI2 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) DP2 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 60.0*+ 1920x1080 50.0 60.0 1920x1080i 50.0 1600x1200 60.0 1680x1050 60.0 1280x1024 60.0 1440x900 59.9 1280x960 60.0 1366x768 59.8 1280x720 50.0 1024x768 60.0 800x60060.3 56.2 720x57650.0 720x48059.9 640x48060.0 59.9 VIRTUAL1 disconnected (normal left inverted right x axis y axis) After I do $ xrandr --output HDMI1 --auto the monitor is no longer detected. $ xrandr | grep HDMI1 HDMI1 disconnected (normal left inverted right x axis y axis) OpenBSD 5.5 (GENERIC.MP) #297: Mon Feb 24 03:47:14 MST 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17033482240 (16244MB) avail mem = 16571445248 (15803MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb740 (78 entries) bios0: vendor American Megatrends Inc. version F3 date 05/02/2013 bios0: GIGABYTE MRHM7AP acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT DMAR ASF! acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz, 1895.99 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz, 1895.70 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz, 1895.70 MHz cpu2:
Re: Intel HD Graphics 4000, only one monitor detected
Date: Wed, 26 Feb 2014 07:38:29 +0100 From: Markus Bergkvist mar...@familjenbergkvist.net 2014-02-14 15:15 GMT+01:00 Markus Bergkvist mar...@familjenbergkvist.net: Synced and verified that kettenis patch was there but unfortunately it did not help with a new kernel. 2014-02-14 9:54 GMT+01:00 Jonathan Gray j...@jsg.id.au: On Fri, Feb 14, 2014 at 08:48:04AM +0100, Markus Bergkvist wrote: I did an update to recent snapshot OpenBSD 5.5-beta (GENERIC.MP) #287: Fri Feb 7 11:45:09 MST 2014 I have two identical monitors connected to my Intel HD Graphics 4000 on DisplayPort and HDMI respectively. Usually there is no problem detecting them both and split my desktop across both monitors. But somewhere between OpenBSD 5.5-beta (GENERIC.MP) #284: Mon Feb 3 07:57:32 MST 2014 and OpenBSD 5.5-beta (GENERIC.MP) #287: Fri Feb 7 11:45:09 MST 2014 something happened. The monitor on HDMI is mirroring the DisplayPort and it is not detected by xrand. Output from xrandr, diff between previous and current dmesg and a complete dmesg below. Any suggestion on what might be wrong? Any more information I can provide? The xf86-video-intel driver was recently updated, this triggered a bug in copying data out of the kernel that was previously hidden which affects xrandr. It would be interesting to see if compiling your own kernel sometime after the following commit by kettenis@ helps: CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2014/02/13 05:33:08 Modified files: sys/dev/pci/drm: drm_crtc.c Log message: Make sure we copy out the right amount of data in the various copyout() calls that replace the put_user() calls in the Linux code by using sizeof on the appropriate variables instead of explicit uint32_t/uint64_t types. Fixes a case where we accidentally copied out only 32 bits of a 64-bit value, uncovered by xf86-video-intel 2.99.909. ok jsg@, matthieu@ Updated to recent snapshot. Monitor on HDMI-port is detected but is disconnected? What does xrandr --verbose say?
